[cmake-developers] Package Config files with COMPONENTS

Alexander Neundorf neundorf at kde.org
Tue Mar 13 16:43:28 EDT 2012


On Tuesday 13 March 2012, Brad King wrote:
> On 3/13/2012 3:25 PM, Alexander Neundorf wrote:
> > How about this:
> > * no policy
> > * new argument find_package( OPTIONAL_COMPONENTS), so we get two sets of
> > components
> > * the components are still ignored by find_package() for setting
> > Foo_FOUND * I add some code to FPHSA so it handled COMPONENTS and
> > REQUIRED_COMPONENTS as done in my branch (i.e. COMPONENTS are required,
> > OPTIONAL_COMPONENTS not) * I maybe add something to @PACKAGE_INIT@ to
> > help Config files handle components as recommended
> > 
> > This way we could recommend to handle components in some way, and make it
> > easy for developers to follow the recommendation.
> 
> Sounds good!
> 
> Rather than two separate lists of components perhaps the
> 
>   <pkg>_FIND_REQUIRED_<component>
> 
> variables could have the value "OPTIONAL" instead of "1" when a
> given component is optional.  

Looks a bit strange IMO.
Both "OPTIONAL" and "1" evaluate to true.
And the value of e.g. Foo_FIND_REQUIRED_Comp would be "OPTIONAL", which kind 
of conflicts with the "REQUIRED" in the name of the variable.

We could also not set <pkg>_FIND_REQUIRED_<component>, or set it to "0" (which 
would mean it is not required).

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.

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

> This will probably simplify code
> dealing with components because it needs to loop over only one
> list 

Hmm, maybe.
foreach(comp ${Foo_FIND_COMPONENTS})
vs.
foreach(comp ${Foo_FIND_COMPONENTS} ${Foo_FIND_OPTIONAL_COMPONENTS})

> and won't have to worry about whether a component can appear
> in both lists.

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'd probably go with the second option.

Alex



More information about the cmake-developers mailing list