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
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
