[cmake-developers] Package Config files with COMPONENTS

[Michael Hertling]

On 03/13/2012 09:55 PM, Brad King wrote:
> On Tue, Mar 13, 2012 at 4:43 PM, Alexander Neundorf <neundorf at kde.org> wrote:
>> We could also not set <pkg>_FIND_REQUIRED_<component>, or set it to "0" (which
>> would mean it is not required).
> 
> Even better.  One can loop over the_FIND_COMPONENTS list and then test
> the variable to see if it is really required or not.
> 
>> Are there any compatibility issue to take into account ?
>> Until now, there never was a OPTIONAL_COMPONENT, so every call to
>> find_package(COMPONENTS ...) will work as before.
> 
> I don't think there is a compatibility concern.  A loop like the above
> would just consider every component required when the package is
> loaded by an older project that does not use the new keyword.
> 
>> If somebody adds a OPTIONAL_COMPONENTS, this will add component entries to the
>> FIND_COMPONENTS variable which have now _FIND_REQUIRED_ set to 0.
>> The Find-module or Config-file may not be prepared to handle this.
> 
> I do not think that is a problem.  The calling project should only use
> this option if the package to be found documents that it supports
> optional components.  This is the same as passing only components
> documented by the package as known.
> 
>> What is actually the purpose of the _FIND_REQUIRED_ variable ?
>> It currently doesn't add any information compared to the list
>> _FIND_COMPONENTS. Are you aware of any uses of this variable ?
> 
> _FIND_REQUIRED_ came first.  The entire feature was first added here:
> 
>   http://www.cmake.org/Bug/view.php?id=2771
>   http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9f625bea
> 
> The _FIND_COMPONENTS list was added later because it is more convenient.
> 
>> The argument parsing in cmFindPackage still has to decide what to do if a
>> component appears multiple times.
>> Error out ?
>> REQUIRED always has priority over OPTIONAL ?
>> Last one wins ?
> 
> I think error is best.  It's better to be explicit so authors do not
> assume ether way.

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?

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.

IMO, this does neither imply inherent contradictions to be handled
by FIND_PACKAGE() nor constrain {FindFoo,FooConfig}.cmake's freedom
to process components in any suitable way. Finally, one could simply
allow arbitrary duplicates after COMPONENTS and OPTIONAL_COMPONENTS.

Note that this does not affect the question whether there should be
a sole comprehensive Foo_FIND_COMPONENTS variable or an additional
Foo_FIND_OPTIONAL_COMPONENTS one.

Regards,

Michael