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

[Eric Noulard]

2012/2/17 Eric Noulard <eric.noulard at gmail.com>:
> 2012/2/17 Alexander Neundorf <neundorf at kde.org>:
>> On Friday 17 February 2012, Eric Noulard wrote:
>>> 2012/2/17 Alexander Neundorf <neundorf at kde.org>:
>>> > On Thursday 16 February 2012, Brad King wrote:
>>> >> On 2/16/2012 1:24 PM, Alexander Neundorf wrote:
>>> >> > Actually I expected I would prefer this over the fixed names, but now
>>> >> > that I've done it and look at what Config.cmake.in file I have to
>>> >> > write, I think I liked the previous version with the fixed names
>>> >> > (CONFIG_HELPER) better. I think it was easier to do, a simple scheme.
>>> >>
>>> >> I think the fixed names are better/simpler too.  I'm not fond of
>>> >> "CONFIG_HELPER" specifically.  The information stored in them is
>>> >> about the *package* that the file is configuring, which is why
>>> >> I originally proposed the prefix "PACKAGE_".  The INCLUDE_INSTALL_DIR
>>> >> is where the *package* goes, not where the config helper is/goes.
>>> >
>>> > I pushed a branch MakingConfigFilesEasier_ConfigureMacro to stage.
>>> > It has documentation and a test.
>>> > An example Config.cmake.in file is attached.
>>> > I can still change names etc. tomorrow.
>>> > The macro is in CMakePackageHelpers.cmake.
>>>
>>> Nice piece of work. Should be helpful to many of us.
>>> Some more "tuning remarks".
>>>
>>> Why not offering more "bundled interface" to this feature ?
>>>
>>> currently you have to:
>>>
>>> 1) include(CMakePackageConfigHelpers)
>>> 2) configure_package_config_file(FooConfig.cmake.in
>>>                       ${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake
>>>                       INSTALL_DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake
>>>                       PATH_VARS INCLUDE_INSTALL_DIR SYSCONFIG_INSTALL_DIR)
>>> 3) write_basic_package_version_file(
>>>                     ${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake
>>>                     VERSION 1.2.3 COMPATIBILITY
>>>                     SameMajorVersion)
>>>
>>> 4) install(FILES ${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake
>>>              ${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake
>>>              DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake )
>>
>> Yes, these are all simple orthogonal functions, which can be described with
>> one sentence without using "and".
>>
>>> 1) is mandatory of course
>>> 3) is optional
>>> 2) and 4) should be using the same "INSTALL_DESTINATION"  and
>>> "DESTINATION" in order to be consistent.
>>>
>>> I cannot imagine doing 2) or 3) without 4).
>>
>> You are right.
>> It is a somewhat problematic point that the destinations must match.
>>
>>> So in the end, wouldn't it be simpler (for the user/developer) to have
>>> something like:
>>>
>>> include(CMakePackageConfigHelpers)
>>> create_and_install_package_config_files(NAME Foo
>>>                    CONFIG_TEMPLATE FooConfig.cmake.in
>>>                    DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake
>>>                    PATH_VARS INCLUDE_INSTALL_DIR SYSCONFIG_INSTALL_DIR
>>>                    VERSION 1.2.3
>>>                    VERSION_COMPATIBILITY SameMajorVersion)
>>>
[...]
>
> So the point is, is there any usefulness from the CMake user point of view,
> in providing such higher-level (but less powerful) API for CMake
> config file at all.

No obvious sign of interest for this idea on the list.
I won't work on "create_and_install_package_config_files" and rather continue
my work on improving CPack doc.

May come to that later after Alex's macros has been merged to master.

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org