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

[Michael Hertling]

On 02/27/2012 10:05 PM, 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.

Some FooConfig.cmake authors might use FPHSA(Foo "..." ...) because
of its messaging capabilities respecting REQUIRED/QUIET, and rely on
FIND_PACKAGE() returning with Foo_FOUND==TRUE even if FPHSA() has set
this variable to FALSE. Note that there is still no convention which
could deprecate this kind of FPHSA()'s usage in config files. Since
the proposed approach will break things in such a case, a policy
would actually be necessary, IMO.

Regarding Foo_DIR: This suits to determine if FooConfig.cmake has
been found, but in module mode, AFAIK, it's set to Foo_DIR-NOTFOUND
even if a find module has succeeded. Similarly, Foo_CONFIG is empty
in module mode or if FooConfig.cmake hasn't been found. Therefore,
my question is still: How can I figure out in a reliable manner
that FIND_PACKAGE(Foo ...) has found neither FindFoo.cmake nor
FooConfig.cmake?

Anyway, I have difficulties to realize the advantages of the
proposed approach. What does work better with it? Where is

Foo_FOUND = Foo_X_FOUND && Foo_Y_FOUND && ...

superior to the status quo?

Regards,

Michael