[cmake-developers] Making Config.cmake files easier to write

Alexander Neundorf neundorf at kde.org
Tue Feb 14 13:26:08 EST 2012


On Monday 13 February 2012, Brad King wrote:
> On 2/13/2012 4:52 PM, Alexander Neundorf wrote:
> > we are hoping that more and more libraries will install Config.cmake
> > files (and for kdelibs this is actually happening right now), so we
> > should make sure it is straighforward to create proper Config.cmake
> > files.
> 
> This is a worthwhile goal, but I do not like the approach proposed:
> 
> (1) It makes BarConfig.cmake depend on a file not distributed with it.

Well, CMakeConfigHelpers.cmake would be shipped with cmake, so as long as the 
Config.cmake file says
cmake_minimum_required(VERSION 2.8.8)
it would be fine.

> (2) The content of a relocatable BarConfig.cmake should not depend on where
> it happened to be installed when the package was built.

I don't see a real problem with this.
Actually it is a good thing if the Config.cmake file can detect whether it is 
in the location where it should be according to CMAKE_INSTALL_PREFIX, e.g. to 
ensure that the libraries are installed in the right location (so the builtin 
RPATHs point to the right location).

> I'd rather see an approach that processes paths during configuration
> of the original package.  Provide some helper macros that can configure
> BarConfig.cmake with the proper code in it to compute paths relative
> to its location:
> 
>   include(CMakePackageConfigHelper)
>   cmake_package_config_for_install(Bar
>     DESTINATION lib/cmake/Bar # install destination
>     # INPUT BarConfig-install.cmake.in # alternate input
>     )
> 
> This would look for "BarConfig.cmake.in" (or whatever INPUT says) and
> do configure_file along with install(FILES).  The module can document
> some standard @CONFIG@ variables that can be used inside the input
> file to get various paths:
> 
>   $ cat BarConfig.cmake.in
>   @PACKAGE_INIT@
>   set(BAR_INCLUDE_DIRS "@PACKAGE_PREFIX@/include/bar")
>   ...
> 
> The @PACKAGE_INIT@ would be replaced by code to compute the install
> prefix using knowledge the of the install DESTINATION of the config
> file and store it in an unspecified variable (say Bar_PREFIX) that
> is referenced by @PACKAGE_PREFIX@, which is replaced by ${Bar_PREFIX}.

How would that work if INCLUDE_INSTALL_DIR is an absolute path ?
set(BAR_INCLUDE_DIRS "@INCLUDE_INSTALL_DIR@")

Would the case that DATA_INSTALL_DIR and LIB_INSTALL_DIR point to completely 
different locations be handled ?

Alex



More information about the cmake-developers mailing list