2012/2/17 Eric Noulard <eric.noul...@gmail.com>:
> 2012/2/17 Alexander Neundorf <neund...@kde.org>:
>> On Friday 17 February 2012, Eric Noulard wrote:
>>> 2012/2/17 Alexander Neundorf <neund...@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
--
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
