[cmake-developers] Package Config files with COMPONENTS

[Brad King]

On Thu, Mar 15, 2012 at 11:41 AM, Michael Hertling <mhertling at online.de> wrote:
> IMO, using solely <pkg>_FIND_REQUIRED_<component> to indicate if
> a requested component is mandatory or optional is not sufficient.
> Consider the following use case:
>
> FIND_PACKAGE(Foo COMPONENTS X OPTIONAL_COMPONENTS Y)
>
> Suppose both X and Y do require a component A. AFAICS, this is a
> completely regular case and provides for a component that should
> conceptually be considered mandatory *and* optional.
>
> In {FindFoo,FooConfig}.cmake, it has proven to be very convenient
> to add such prerequisite components to Foo_FIND_COMPONENTS at the
> beginning in order to process all components in a unique manner
> later on. Which value should one set Foo_FIND_REQUIRED_A to?

Use unset().  The other values are set by find_package to tell the
find module or package config file what the caller wants.  Since the
user didn't specify an explicit preference for A then use the fact
that the value is not set to know that.  The find_package command
doesn't pay attention to these variables as output so I couldn't care
less how a find module or package configuration file messes with them
internally for its own logic.

Unlike <pkg>_FOUND and <pkg>_<comp>_FOUND the meaning of
<pkg>_FIND_REQUIRED_<comp> and <pkg>_FIND_COMPONENTS are defined by
find_package rather than the individual package.  This is a place
where a strict convention should be used.  It should be well defined
what a given call to find_package is requesting from the package.  The
design on which Alex and I settled achieves that.

> Instead, I'd suggest not to touch the value of Foo_FIND_REQUIRED_*
> but to add a further variable like Foo_FIND_OPTIONAL_*, as it is
> already done in 1a157e7. Then, just accept it if both variables
> are TRUE and leave it to {FindFoo,FooConfig}.cmake how to handle
> this case, i.e. bail out, prefer REQUIRED to OPTIONAL or whatever.

Introducing more variables will just lead to more state combinations
that need to be defined and understood by all parties on a per-package
basis.  It is much simpler to say that a component cannot be both
required and optional.

-Brad