[cmake-developers] How to handle package Config.cmake files with dependencies ?

Alexander Neundorf neundorf at kde.org
Sat Mar 10 07:35:37 EST 2012


On Monday 27 February 2012, Brad King wrote:
> On 2/27/2012 3:37 PM, Michael Wild wrote:
> > On 02/27/2012 09:15 PM, Alexander Neundorf wrote:
> >> When the FooConfig.cmake has been found, Foo_FOUND is set to TRUE:
> >>   // Set a variable marking whether the package was found.
> >>   
> >>    std::string foundVar = this->Name;
> >>    foundVar += "_FOUND";
> >> 
> >> This means it is true in all cases that the Config.cmake file has been
> >> found (and the version was compatible).
> 
> The find_package command is acting as a primitive like find_library from
> the point of view of setting Foo_DIR, and that can be tested directly to
> see if the config file was found.  That leaves room to change the way
> we set Foo_FOUND.  We could add a policy that in NEW behavior unsets
> Foo_FOUND completely before loading FooConfig.  After FooConfig has been
> loaded it detects whether Foo_FOUND is now defined.  If set, use that
> value.  If not set, set it to true as it is now.  That will give the
> FooConfig file a chance to set the result.

There is now a branch find_package_set_FOUND_VariableInConfigFile on stage.

It behaves almost as you suggested: the _FOUND variable is only removed before 
the Config file is loaded, if the variable exists and is false.

So if some Config file would test for the previous value of _FOUND, it will 
still get the same result.

After the Config file is loaded, it checks whether _FOUND now exists and 
whether it is set to FALSE.
Only in this case find_package() now sets _FOUND to FALSE although a Config 
file has been found and could be processed.

I didn't add a policy.
I'm not sure it is necessary. I'm tempted to consider this a bug fix, and 
whoever relies on the fact that Foo_FOUND=FALSE will be overridden has a 
broken setup.
However, if this was the case, it would hit users of the installed Config 
files.

So, I'm not sure about the policy.

I can add one if you consider it necessary.

Alex



More information about the cmake-developers mailing list