[CMake] Abuse of find_package COMPONENTS, or not?

[Philip Lowman]

On Mon, May 25, 2009 at 4:08 AM, Marcel Loose <loose at astron.nl> wrote:

> 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?


You'll have to use your discretion.  A string may be a far better choice if
using a boolean might be confusing.  It is certainly a no brainer if there
are more than two choices available.

I don't recommend using option() internally in CMake find modules because
the end user might not want the option to show up in his build system.  If
he does, he can always add an option() to his own code (and set his own
default).  There may be exceptions to this which make sense but
single/double precision doesn't seem like it would qualify in my mind. I
would think most users are going to want one or the other most of the time
for a particular application.

All in all, I think breaking up the choices into distinct variable names
will make your module easier to use in the long run and it also becomes more
self documenting at that point.  It sounds like for the moment you'll only
need two variables to me: one for single/double precision and one for
parallelization.


-- 
Philip Lowman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20090525/3a346e2e/attachment.htm>