[cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree

[Daniele E. Domenichelli]

On 21/07/14 21:04, 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? 


I have at least a couple of different cases where I would like to be
able to do this.

The first case is a folder that is appended to CMAKE_MODULE_PATH, and
that containing CMake files that can optionally be included by projects
using this package.

The second case is a path to a folder containing "data" files installed
by the library (that usually go in <prefix>/share/<something>), and that
other projects should be able to use.

In both cases I need to pass a path to the project, not to include a
file. The files that the projects need to use are not in
${CMAKE_CURRENT_LIST_DIR} (relative to the config files) and the
relative path is different, since for the build tree the cmake config
files are in ${CMAKE_BINARY_DIR} (as expected for example by the package
registry), while for the install tree the config files are in some of
the directory searched by find_package (depending on the OS).


> 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?

CMakePackageConfigHelpers _can_ already solve this problem, but you have
to pass _absolute_ paths to configure_package_config_file, and that is
different from everywhere else in CMake.


> 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.

Does this mean that configure_package_config_file is going to be
deprecated and should not be used for new packages? If that's the case,
maybe the documentation should mention it. Anyway, even when creating
targets in a modern way, I still believe that it is a very useful module
when you need to pass paths that cannot be encoded into imported targets.


Cheers,
 Daniele