[CMake] Abuse of find_package COMPONENTS, or not?

[Marcel Loose]

OK, thanks Philip and others.

BTW: FFTW is a library for calculating Fast Fourier Transforms. Version
2 of that library supports both single and double precision, but they're
mutually exclusive, i.e. you cannot mix them. It also offers two ways of
parallelization, mpi and threads, which are (AFAIK) also mutually
exclusive. 

I was looking for a way to pass this kind of information (single/double
precision mpi/threads/no parallelization) in an easy way to
find_package(). That's why I ended up using components. The other way to
go is use variables. But, since you cannot pass variables to
find_package(), the user of FindFFTW would have to set these variables
in advance, instead of just having to type a one-liner. I (as
implementer of FindFFTW.cmake) would still need to test for mutually
exclusive settings, whether it'd be variables or components. 

On the other hand, it doesn't feel right to use components this way;
that's the reason I posted this question. Do you suggest to use options?
In that case, is it possible to group options somehow (I vaguely
remember I read a discussion on that topic on the mailing list some time
ago), to handle mutual exclusiveness. Or would it be better to go for
strings and test for a limited number of valid values?

Best regards,
Marcel Loose.


-----Original Message-----
From: Philip Lowman <philip at yhbt.com>
To: Marcel Loose <loose at astron.nl>
Cc: denis_scherbakov at yahoo.com, cmake at cmake.org
Subject: Re: [CMake] Abuse of find_package COMPONENTS, or not?
Date: Wed, 20 May 2009 23:00:37 -0400

On Wed, May 20, 2009 at 10:51 AM, Marcel Loose <loose at astron.nl> wrote:
        Hi Denis,
        
        Kind of you to let me decide ;-)
        
        But seriously, I posted this question, because I wanted to know
        whether
        this is the CMake-way of doing things. Not because I like to
        write the
        macro that way.
        
        In the end, maybe a larger community might want to use this
        macro. If
        so, then it would really help if it adheres to some (unwritten)
        standards.

I suggest you avoid using COMPONENTS unless you're dealing with a
package which is broken up into several components at least one of which
is optional.  I agree with Denis and Adolfo that you should use a
variable to differentiate between the single and multithreaded versions
of the library.

If you start using a list where you should be using a boolean, the end
user is just going to end up being confused.  You're also going to
manufacture additional error conditions that you'll have to handle in
your code.

If for some reason your goal is concurrent searching for single and
multithreaded libraries so a user can use either in the same project
(not sure why anyone would want to do this but I don't even know what
FFTW stands for) you're far better off searching for both, i.e.
FOO_ST_LIBRARY & FOO_MT_LIBRARY and then choosing which gets set in
FOO_LIBRARIES via a boolean.


-- 
Philip Lowman