[cmake-developers] [Review Request] Topic CMakePackageConfigHelpers_build_tree

[Stephen Kelly]

Daniele E. Domenichelli wrote:

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

I still find this an odd user interface.

You provide a variable FOO_MODULE_PATH or something and document that users 
should add that to their CMAKE_MODULE_PATH after invoking find_package? Then 
what? The user needs to know which files they can include(). Do you leave 
the user to run ls to find out what's there or do you document them for your 
package?

Instead of all that, you could provide and document variables (ala 
QT_USE_FILE) which the users pass directly to include(). I would find that a 
better user interface and less fragile.

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

I guess if you have a particular structure in the source tree, you might not 
want to symlink/replicate it to the build tree. That arises for qml files 
for example. However, usually I have chosen the symlink/copy route.

As you can see here, the CMakePackageConfigHelpers is only needed for 
'backward compatibility' provision of the INCLUDE_DIRS variable, which 
wouldn't be added in new code:

 https://github.com/KDAB/KDSoap/blob/master/CMakeLists.txt#L92
 https://github.com/KDAB/KDSoap/blob/master/KDSoapConfig.cmake.in

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

Some other places you can have the cmake config file for the build tree:

 ${CMAKE_BINARY_DIR}/cmake
 ${CMAKE_BINARY_DIR}/<project-name>
 ${CMAKE_BINARY_DIR}/<project-name>/cmake
 ${CMAKE_BINARY_DIR}/cmake/<project-name>
 ${CMAKE_BINARY_DIR}/lib/cmake/<project-name>
 ${CMAKE_BINARY_DIR}/lib/cmake

Depending on whether you're going for 'cleanliness' or similarity to the 
installed layout etc.


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

No, it does not mean that. It means I was trying to find out why you need 
it. My current understanding is that the things it does can also be done 
other ways (and better ways I think as with the variables for include() 
above).

> I still believe that it is a very useful module
> when you need to pass paths that cannot be encoded into imported targets.

I was trying to find out if that points us to a gap in the first-class 
features provided by cmake.

Thanks,

Steve.