[cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree

[Stephen Kelly]

Daniele E. Domenichelli wrote:

> On 21/07/14 14:23, Stephen Kelly wrote:
>> Can you give a more-concrete example of what the problem is?
> 
> The project is supposed to work both from build tree (using
> export(TARGETS)) and from the install tree (using install(EXPORT)).

Your example is too abstract. What is the meaning of the paths? 

What is the problem which can be solved only with CMakePackageConfigHelpers 
and can't be solved (currently) another way? Is there a first-class feature 
CMake could learn to make this stuff easier?

Here is why I am asking:

The documentation at

 http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#creating-packages

does not use CMakePackageConfigHelpers because for 'modern' packages, paths 
such as include directories are encoded into imported targets. Then the 
complete FooConfig.cmake file is:

 include(CMakeFindDependencyMacro)
 find_dependency(Stats 2.6.4)

 include("${CMAKE_CURRENT_LIST_DIR}/ClimbingStatsTargets.cmake")
 include("${CMAKE_CURRENT_LIST_DIR}/ClimbingStatsMacros.cmake")

and it works as both a build-location package and an install-location 
package, without using CMakePackageConfigHelpers. 

That is assuming the ClimbingStatsMacros.cmake can be generated in or copied 
to the build location. That is an easy assumption to make, because it is 
easy to do such generation or copying.

So, I am trying to find out:

 When using 'modern cmake', is there a remaining need for 
CMakePackageConfigHelpers?


Thanks,

Steve.