[cmake-developers] CMakeFindDependencyMacro limitations

Stephen Kelly steveire at gmail.com
Sat Mar 5 05:53:57 EST 2016


Roger Leigh wrote:

> On 24/02/2016 22:49, Roger Leigh wrote:
>> I've attached a patch for a very simple modification to find_dependency.
>>   I'm not proposing that it be merged, it's just a suggestion for
>> further discussion.  I've tested it with my own packages with multiple
>> find_dependency(Boost COMPONENTS ...) calls.  Some rationale and
>> thoughts follow:
> 
> Did anyone have any time to take a look at this?  Are there any
> objections or further questions arising from the approach taken here?
> Could it be submitted for inclusion if not?

I still see the find_dependency limitation as a useful one, given how much 
confusion removing it would cause.

 find_package(foo)
 find_package(bar)

 if (Qt5_FOUND) # TRUE!
 endif()

6 months later...

 find_package(foo)
 find_package(bar)
 find_package(bing)

 if (Qt5_FOUND) # FALSE!
 endif()


My recommendation is: figure out the underlying truth about find_package 
COMPONENTS and multiple find_package calls. 

This isn't a matter of opinion - it is inherent to how find_package and the 
cmake cache, and cmake scoping work. 

As far as I know, no one has thought it through thoroughly.

You might find this interesting:

 http://public.kitware.com/Bug/view.php?id=15971

As I wrote there,

> Also, a user might expect
> multiple find_package in the same scope (as with transitive package
> dependencies) to be 'reliable'. As far as I know it is not.

It doesn't matter if things like that have been done for years if they have 
never been reliable and if there has never been a possible way to do it 
correctly. 

The statement is not at all about find_dependency, but is about whether it 
was ever possible (or is possible now) for someone to put correct lines into 
their Config.cmake package (or possibly into a Find module) which would make 
multiple find_package of the same package with different COMPONENTS 
reliable. 

My suspicion is it was never possible (independent of existence or not of 
any macro). That's what I'm suggesting you to investigate and discover. This 
is something to discover (based on inherent truths about the cmake cache, 
scoping, find_package features etc. I'm repeating myself), not something to 
'decide'.

You might find that COMPONENTS is incompatible/confusing/unreliable with 
other parts of CMake, or you might find that it actually makes sense. I'm 
just suggesting a full investigation completely independent of the 
find_dependency macro.

Thanks,

Steve.




More information about the cmake-developers mailing list