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. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
