[cmake-developers] cmake --find-package (was: Roadmap to CMake 3.0)

[Alexander Neundorf]

On Thursday 17 October 2013, Stephen Kelly wrote:
> Brad King wrote:
> > On 10/17/2013 04:58 PM, Alexander Neundorf wrote:
> >> Yes, that was the idea, but I can't rely anymore on a Foo_LIBRARIES
> >> variable (or a slight variation) being set after a successful
> >> find_package(Foo):
> >> http://lists.kde.org/?l=kde-core-devel&m=138198795723680&w=2 I.e. in the
> >> future there will be Find-modules which typically export one of
> >> (Foo|FOO)_(LIBRARIES|LIBRARY), some Config.cmake files which do that
> >> too, and a big number, probably majority, of Config.cmake files, which
> >> do not export such variables.
> >> 
> >> The only chance I see would be to simply collect all library targets and
> >> return what they provide, but this doesn't feel good. I would have much
> >> prefered using a clear interface like the Foo_LIBRARIES variable.
> > 
> > Perhaps we need to establish a convention for find modules and package
> > configuration files to interact with --find-package mode.  I have no
> > thoughts on the specifics of how that would work though.
> 
> A new, similar --find-target mode or similar may be more appropriate:
> 
>  cmake --find-target --package Qt5Widgets --target Qt5::Widgets ...
> 
>  # KF5Config exports 3 independent targets:
>  cmake --find-target --package KF5Config --target KF5::ConfigCore ...
>  cmake --find-target --package KF5Config --target KF5::ConfigGui ...
>  cmake --find-target --package KF5Config --target KF5::ConfigWidgets ...


Yes, that will work.
And a new command/option is not even necessary.
The name of the target could be given as additional option.
If none is given, it will use the variables as it does now, if a target is 
given, it will use this target and its properties.

I'll work on that when I find the time (and nobody is faster).

Alex