Re: [cmake-developers] Making Config.cmake files easier to write
On Friday 02 March 2012, David Cole wrote: Alex, Brad and I reviewed the MakingConfigFilesEasier_ConfigureMacro topic, but have two small additional changes to request before we merge it to master. (1) There's a generated comment referencing ConfigureConfigFile.cmake but there is no such file. Please change that to CMakePackageConfigHelpers.cmake. Ok. And (2) you are using the PACKAGE_HELPER_ prefix... I thought the prefix was intended simply to be PACKAGE_. After you fix up those two minor points, we'll merge it to 'master' next time. So instead of: # @PACKAGE_HELPER_INIT@ # ... # set_and_check(FOO_INCLUDE_DIR @PACKAGE_HELPER_INCLUDE_INSTALL_DIR@) # set_and_check(FOO_SYSCONFIG_DIR @PACKAGE_HELPER_SYSCONFIG_INSTALL_DIR@) you prefer the following ? # @PACKAGE_INIT@ # ... # set_and_check(FOO_INCLUDE_DIR @PACKAGE_INCLUDE_INSTALL_DIR@) # set_and_check(FOO_SYSCONFIG_DIR @PACKAGE_SYSCONFIG_INSTALL_DIR@) , i.e. without HELPER for both the INIT as well as for the actual helper variables ? I can do that, but I think at least for the variables the HELPER makes sense. 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
Re: [cmake-developers] Making Config.cmake files easier to write
On 3/5/2012 5:04 PM, Alexander Neundorf wrote: So instead of: # @PACKAGE_HELPER_INIT@ # ... # set_and_check(FOO_INCLUDE_DIR @PACKAGE_HELPER_INCLUDE_INSTALL_DIR@) # set_and_check(FOO_SYSCONFIG_DIR @PACKAGE_HELPER_SYSCONFIG_INSTALL_DIR@) you prefer the following ? Yes. # @PACKAGE_INIT@ # ... # set_and_check(FOO_INCLUDE_DIR @PACKAGE_INCLUDE_INSTALL_DIR@) # set_and_check(FOO_SYSCONFIG_DIR @PACKAGE_SYSCONFIG_INSTALL_DIR@) I can do that, but I think at least for the variables the HELPER makes sense. We've been through this on the thread earlier when it was CONFIG_HELPER. The information contained in the variables is about the PACKAGE, not about the HELPER. It is PACKAGE_INCLUDE_INSTALL_DIR because the include dir is for the PACKAGE. Even the _INIT variable contains code that computes information about the PACKAGe. There is precedent for this in the find_package command's interface for package version files. -Brad -- 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
Re: [cmake-developers] Making Config.cmake files easier to write
Alex, Brad and I reviewed the MakingConfigFilesEasier_ConfigureMacro topic, but have two small additional changes to request before we merge it to master. (1) There's a generated comment referencing ConfigureConfigFile.cmake but there is no such file. Please change that to CMakePackageConfigHelpers.cmake. And (2) you are using the PACKAGE_HELPER_ prefix... I thought the prefix was intended simply to be PACKAGE_. After you fix up those two minor points, we'll merge it to 'master' next time. Thanks, David On Tue, Feb 21, 2012 at 3:59 PM, Brad King brad.k...@kitware.com wrote: On 2/21/2012 3:17 PM, Alexander Neundorf wrote: On Friday 17 February 2012, Alexander Neundorf wrote: So, I'm not that sure that using PACKAGE instead of CONFIG is really better (the branch I pushed uses PACKAGE, but I could change this again). Ok, so we stay here with PACKAGE, also in the light of the new CONFIG keyword for find_package() ? Yes. The information contained in the generated variable values is about the target package, not about the configuration file storing the info. Thanks, -Brad -- 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 -- 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
Re: [cmake-developers] Making Config.cmake files easier to write
On Friday 17 February 2012, Alexander Neundorf wrote: 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. It's also the same as the package version file input/output variable names. I looked a bit around cmFindPackage. It has a parameter CONFIGS, it has a Config mode and the documentation and error messages use configuration file. So, I'm not that sure that using PACKAGE instead of CONFIG is really better (the branch I pushed uses PACKAGE, but I could change this again). Ok, so we stay here with PACKAGE, also in the light of the new CONFIG keyword for find_package() ? 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
Re: [cmake-developers] Making Config.cmake files easier to write
On 2/21/2012 3:17 PM, Alexander Neundorf wrote: On Friday 17 February 2012, Alexander Neundorf wrote: So, I'm not that sure that using PACKAGE instead of CONFIG is really better (the branch I pushed uses PACKAGE, but I could change this again). Ok, so we stay here with PACKAGE, also in the light of the new CONFIG keyword for find_package() ? Yes. The information contained in the generated variable values is about the target package, not about the configuration file storing the info. Thanks, -Brad -- 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
Re: [cmake-developers] Making Config.cmake files easier to write
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
Re: [cmake-developers] Making Config.cmake files easier to write
On Saturday 18 February 2012, Eric Noulard wrote:
...
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.
sign of interest / ;-)
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
Re: [cmake-developers] Making Config.cmake files easier to write
On Friday 17 February 2012, Eric Noulard wrote: 2012/2/16 Brad King brad.k...@kitware.com: ... the real install location, DESTDIR, or a tarball that was extracted at an arbitrary location on another machine. The load-time prefix is computed relative to the file's location. Under that prefix the file refers to all the other pieces (include, etc.) which exist at a fixed location relative to BarConfig.cmake. Right I did not realize that relative position should still be valid. In fact I'm pretty sure you can break this if you mess-up with absolute install destination, but if ones to that there is no point in using this so... It works with absolute install destinations as long as they point to subdirectories of CMAKE_INSTALL_PREFIX. If they point somewhere else, they are really fixed. 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
Re: [cmake-developers] Making Config.cmake files easier to write
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 )
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).
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)
This would do the same as 1) + 2) + 3) +4) but...
a) enforces that 2) INSTALL_DESTINATION and 4) DESTINATION are the same
and produce appropriate install rule.
b) enforces that whatever the name of the CONFIG_TEMPLATE you end up with
NAMEConfig.cmake
and
NAMEConfigVersion.cmake
I think this is a good point because you don't have the choice of
the name do you?
c) VERSION and VERSION_COMPATIBILITY should be optional parameters
that would trigger
the creation (and install rule) of NAMEConfigVersion.cmake
I can try to write (probably tomorrow) the proposed macro using those
provided by Alex
if you find the idea useful. The proposed macro is not meant replace
the Alex's one but
to offer higher-level [possibly] simpler API.
PS: I start to think in most simple cases CONFIG_TEMPLATE could be
made optional as well
if we add another TARGET_EXPORT_FILE option which indicates the name of
export(TARGETS ... FILE ...), using this a proper config
template could be created as well.
PS2: we may need to add an optional COMPONENT option as well if the
generated install rule should
be put in some install component.
--
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
Re: [cmake-developers] Making Config.cmake files easier to write
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)
This would do the same as 1) + 2) + 3) +4) but...
a) enforces that 2) INSTALL_DESTINATION and 4) DESTINATION are the
same and produce appropriate install rule.
This is good on one side, but on the other side I always try not to hide
simple cmake commands.
I mean, every cmake-using developer should know configure_file() and
install(FILES). IMO it is ok if they have to use those functions.
Now for the Config file the issue is that it is somewhat complicated to get
them relocatable, so we need a helper here.
Combining the install() command into this macro hides the install(), i.e. if I
would search the CMakeLists.txt for install command, to find out what is
installed, I might not notice that this
create_and_install_package_config_files() wraps an install() command.
That's why I kept the install() out of the macro, so that for installing
anything there is always an install() command visible.
(this is a not sure we should do this, not a I seriously object to this
idea)
I agree with all this, and like I said my proposal was not about replacing
your set macros but more like offering an extra high-level one.
b) enforces that whatever the name of the CONFIG_TEMPLATE you end up
with NAMEConfig.cmake
and
NAMEConfigVersion.cmake
I think this is a good point because you don't have the choice of
the name do you?
...and the macro should FATAL_ERROR if CONFIG_TEMPLATE doesn't match
*Config.cmake.in or *-config.cmake.in ?
Sounds ok.
c) VERSION and VERSION_COMPATIBILITY should be optional parameters
that would trigger the creation (and install rule) of
NAMEConfigVersion.cmake
Maybe. OTOH, is there any reason to install a package without version numbers
?
None I think but we could offer a way to the developer to craft his
own Version file
so if those are not specified this means that the developer is
handling this by himself.
PS: I start to think in most simple cases CONFIG_TEMPLATE could be
made optional as well if we add another TARGET_EXPORT_FILE option which
indicates the name of export(TARGETS ... FILE ...), using this a proper
config template could be created as well.
We discussed that too
Re: [cmake-developers] Making Config.cmake files easier to write
On Friday 17 February 2012, Eric Noulard wrote: ... PS: I start to think in most simple cases CONFIG_TEMPLATE could be made optional as well if we add another TARGET_EXPORT_FILE option which indicates the name of export(TARGETS ... FILE ...), using this a proper config template could be created as well. We discussed that too already. Sorry, I surely missed this part if the discussion, next time don't bother re-explaining me I'll go and dig the ML. Not sure whether it was here or on kde-buildsystem. ...agree to everything else. 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
Re: [cmake-developers] Making Config.cmake files easier to write
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. It's also the same as the package version file input/output variable names. I looked a bit around cmFindPackage. It has a parameter CONFIGS, it has a Config mode and the documentation and error messages use configuration file. So, I'm not that sure that using PACKAGE instead of CONFIG is really better (the branch I pushed uses PACKAGE, but I could change this again). 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
Re: [cmake-developers] Making Config.cmake files easier to write
Eric Noulard wrote: 2012/2/17 Alexander Neundorf neund...@kde.org: We discussed that too already. Sorry, I surely missed this part if the discussion, next time don't bother re-explaining me I'll go and dig the ML. A digest of the old discussion. The only non-bloated version of do all the cmake-config magic command I see is write_basic_config_file_for_export(MyExport). This would require some changes on C++ side (i.e., make it possible to query MyExport DESTINTATION, NAMESPACE, list of targets etc.). And this will work only for simple cases (e.g., a few libraries/executables with simple version logic). -- Yury G. Kudryashov, mailto: ur...@mccme.ru -- 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
Re: [cmake-developers] Making Config.cmake files easier to write
On 2/16/2012 10:15 AM, Alexander Neundorf wrote: On Thursday 16 February 2012, Brad King wrote: In hindsight that name was poorly chosen. I'd really like to see package in the name because they are package configuration files. Otherwise there is no indication it has anything to do with find_package. Well, it has to do with Config files :-) Okay, so it can have PackageConfig in its name since they are package configuration files. So which one ? 1) configure_config_file() + write_basic_config_version_file() 2) configure_package_file() + write_basic_config_version_file() 3) configure_package_file() + write_basic_package_version_file() Personally, I prefer 1) and 3) over 2). include(CMakePackageConfigHelper) # CMakeConfigHelper is ambiguous IMO configure_package_config_file(...) write_basic_config_version_file(...) # no need to change name -Brad -- 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
Re: [cmake-developers] Making Config.cmake files easier to write
On Thursday 16 February 2012, Brad King wrote: On 2/16/2012 10:15 AM, Alexander Neundorf wrote: On Thursday 16 February 2012, Brad King wrote: In hindsight that name was poorly chosen. I'd really like to see package in the name because they are package configuration files. Otherwise there is no indication it has anything to do with find_package. Well, it has to do with Config files :-) Okay, so it can have PackageConfig in its name since they are package configuration files. So which one ? 1) configure_config_file() + write_basic_config_version_file() 2) configure_package_file() + write_basic_config_version_file() 3) configure_package_file() + write_basic_package_version_file() Personally, I prefer 1) and 3) over 2). include(CMakePackageConfigHelper) # CMakeConfigHelper is ambiguous IMO configure_package_config_file(...) write_basic_config_version_file(...) # no need to change name Ok, so we have 1) configure_config_file() + write_basic_config_version_file() 2) configure_package_file()+ write_basic_config_version_file() 3) configure_package_file()+ write_basic_package_version_file() 4) configure_package_config_file() + write_basic_config_version_file() 5) configure_package_config_file() + write_basic_package_version_file() 6) configure_package_config_file() + write_basic_package_config_version_file() My choice would be: 1), 5), 6), 3), 4), 2) So, 5) ? 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
Re: [cmake-developers] Making Config.cmake files easier to write
On 2/16/2012 10:48 AM, Alexander Neundorf wrote: 5) configure_package_config_file() + write_basic_package_version_file() So, 5) ? Looks good. Thanks. -Brad -- 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
Re: [cmake-developers] Making Config.cmake files easier to write
On Thu, Feb 16, 2012 at 10:52 AM, Brad King brad.k...@kitware.com wrote: On 2/16/2012 10:48 AM, Alexander Neundorf wrote: 5) configure_package_config_file(**) + write_basic_package_version_** file() So, 5) ? Looks good. Thanks. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/** opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-**bin/mailman/listinfo/cmake-**developershttp://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers Sorry to be a latecomer to the conversation here, but is anybody else concerned about potential confusion between PackageConfig and PkgConfig? -- 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
Re: [cmake-developers] Making Config.cmake files easier to write
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. It's also the same as the package version file input/output variable names. -Brad -- 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
Re: [cmake-developers] Making Config.cmake files easier to write
On 2/16/2012 3:29 PM, Eric Noulard wrote: What are you targeting? install-time i.e. make install usage? package install time prodduced with cpack usage? package install time NOT produced with cpack usage? a subset of this? The goal is a FooConfig.cmake file for make install time but that contains no hard-coded paths referring to the install prefix. It should be totally relocatable. I think we've resolved all that in the other parts of this thread. -Brad -- 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
Re: [cmake-developers] Making Config.cmake files easier to write
2012/2/16 Brad King brad.k...@kitware.com:
On 2/16/2012 3:29 PM, Eric Noulard wrote:
What are you targeting?
install-time i.e. make install usage?
package install time prodduced with cpack usage?
package install time NOT produced with cpack usage?
a subset of this?
The goal is a FooConfig.cmake file for make install time but
that contains no hard-coded paths referring to the install prefix.
It should be totally relocatable. I think we've resolved all
that in the other parts of this thread.
I'm not convinced, yet I'll have to try with the example provided by Alex
by adding proper CPack usage in it.
Currently I see in BarConfig.cmake
get_filename_component(BAR_HELPER_PREFIX_DIR
${CMAKE_CURRENT_LIST_DIR}/../../../ ABSOLUTE)
computed by CONFIGURE_CONFIG_FILE with
if(NOT IS_ABSOLUTE ${CCF_INSTALL_DESTINATION})
set(absInstallDir ${CMAKE_INSTALL_PREFIX}/${CCF_INSTALL_DESTINATION})
endif()
file(RELATIVE_PATH CONFIG_RELATIVE_PATH ${absInstallDir}
${CMAKE_INSTALL_PREFIX} )
where you can see the usage of CMAKE_INSTALL_PREFIX.
since CPack is using DESTDIR in order to do its local install before
actual packaging
I cannot see how this could work with CPack but again I may be simply
missing the point
I'll try to follow the thread tomorrow and try by myself.
--
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
Re: [cmake-developers] Making Config.cmake files easier to write
On Thu, Feb 16, 2012 at 3:52 PM, Eric Noulard eric.noul...@gmail.comwrote:
2012/2/16 Brad King brad.k...@kitware.com:
On 2/16/2012 3:29 PM, Eric Noulard wrote:
What are you targeting?
install-time i.e. make install usage?
package install time prodduced with cpack usage?
package install time NOT produced with cpack usage?
a subset of this?
The goal is a FooConfig.cmake file for make install time but
that contains no hard-coded paths referring to the install prefix.
It should be totally relocatable. I think we've resolved all
that in the other parts of this thread.
I'm not convinced, yet I'll have to try with the example provided by Alex
by adding proper CPack usage in it.
Currently I see in BarConfig.cmake
get_filename_component(BAR_HELPER_PREFIX_DIR
${CMAKE_CURRENT_LIST_DIR}/../../../ ABSOLUTE)
computed by CONFIGURE_CONFIG_FILE with
if(NOT IS_ABSOLUTE ${CCF_INSTALL_DESTINATION})
set(absInstallDir ${CMAKE_INSTALL_PREFIX}/${CCF_INSTALL_DESTINATION})
endif()
file(RELATIVE_PATH CONFIG_RELATIVE_PATH ${absInstallDir}
${CMAKE_INSTALL_PREFIX} )
where you can see the usage of CMAKE_INSTALL_PREFIX.
since CPack is using DESTDIR in order to do its local install before
actual packaging
I cannot see how this could work with CPack but again I may be simply
missing the point
I'll try to follow the thread tomorrow and try by myself.
--
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
It can't work with CPack, not in the sense of work as in the software
will run from its DESTDIR-based intermediate CPack driven install location
However, it is a correct config file that will work when an end user
installs it from an rpm or a deb package. (Or an NSIS installer on
Windows...) In fact, it will work regardless of where they install it.
Remember, these config files should not actually be processed by anything
when they are in that DESTDIR CPack install tree, though.
David
--
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
Re: [cmake-developers] Making Config.cmake files easier to write
On 2/16/2012 4:13 PM, David Cole wrote:
On Thu, Feb 16, 2012 at 3:52 PM, Eric Noulard eric.noul...@gmail.com
mailto:eric.noul...@gmail.com wrote:
I'm not convinced, yet I'll have to try with the example provided by Alex
by adding proper CPack usage in it.
Currently I see in BarConfig.cmake
get_filename_component(BAR_HELPER_PREFIX_DIR
${CMAKE_CURRENT_LIST_DIR}/../../../ ABSOLUTE)
[snip]
It can't work with CPack, not in the sense of work as in the
software will run from its DESTDIR-based intermediate CPack
driven install location
It can. The main feature of what Alex wrote based on a combination
of his, Yury's, and my ideas is that the generated BarConfig.cmake has
no hard-coded paths containing the installation prefix in any form,
DESTDIR or not. The line
get_filename_component(BAR_HELPER_PREFIX_DIR
${CMAKE_CURRENT_LIST_DIR}/../../../ ABSOLUTE)
is evaluated when BarConfig.cmake is *loaded* at which point the
${CMAKE_CURRENT_LIST_DIR} will be replaced with the *current* location
of the file as it exists when loaded. It doesn't matter if it is in
the real install location, DESTDIR, or a tarball that was extracted
at an arbitrary location on another machine. The load-time prefix
is computed relative to the file's location. Under that prefix the
file refers to all the other pieces (include, etc.) which exist at
a fixed location relative to BarConfig.cmake.
-Brad
--
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
Re: [cmake-developers] Making Config.cmake files easier to write
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.
Alex
# set the version of myself
set(BAR_VERSION_MAJOR @BAR_VERSION_MAJOR@)
set(BAR_VERSION_MINOR @BAR_VERSION_MINOR@)
set(BAR_VERSION_PATCH @BAR_VERSION_PATCH@)
set(BAR_VERSION ${BAR_VERSION_MAJOR}.${BAR_VERSION_MINOR}.${BAR_VERSION_PATCH} )
@PACKAGE_HELPER_INIT@
set_and_check(BAR_INCLUDE_DIR @PACKAGE_HELPER_INCLUDE_INSTALL_DIR@)
set_and_check(BAR_BIN_DIR @PACKAGE_HELPER_BIN_INSTALL_DIR@)
set(BAR_DATA_DIR@PACKAGE_HELPER_DATA_INSTALL_DIR@)
set(BAR_BAR_DIR @PACKAGE_HELPER_BAR_INSTALL_DIR@)
set(BAR_FOO_DIR @PACKAGE_HELPER_FOO_INSTALL_DIR@)
# what is my include directory
set(BAR_INCLUDES ${BAR_INCLUDE_DIR})
# import the exported targets
include(${CMAKE_CURRENT_LIST_DIR}/BarTargets.cmake)
# set the expected library variable
set(BAR_LIBRARIES bar )
--
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
Re: [cmake-developers] Making Config.cmake files easier to write
2012/2/16 Brad King brad.k...@kitware.com:
On 2/16/2012 4:13 PM, David Cole wrote:
On Thu, Feb 16, 2012 at 3:52 PM, Eric Noulard eric.noul...@gmail.com
mailto:eric.noul...@gmail.com wrote:
I'm not convinced, yet I'll have to try with the example provided by
Alex
by adding proper CPack usage in it.
Currently I see in BarConfig.cmake
get_filename_component(BAR_HELPER_PREFIX_DIR
${CMAKE_CURRENT_LIST_DIR}/../../../ ABSOLUTE)
[snip]
It can't work with CPack, not in the sense of work as in the
software will run from its DESTDIR-based intermediate CPack
driven install location
It can. The main feature of what Alex wrote based on a combination
of his, Yury's, and my ideas is that the generated BarConfig.cmake has
no hard-coded paths containing the installation prefix in any form,
DESTDIR or not. The line
get_filename_component(BAR_HELPER_PREFIX_DIR
${CMAKE_CURRENT_LIST_DIR}/../../../ ABSOLUTE)
is evaluated when BarConfig.cmake is *loaded* at which point the
${CMAKE_CURRENT_LIST_DIR} will be replaced with the *current* location
of the file as it exists when loaded.
Yes right I got that, my point was that the /../../../
which was computed at configure time was computed w.r.t. CMAKE_INSTALL_PREFIX
know at CMake-time.
It doesn't matter if it is in
the real install location, DESTDIR, or a tarball that was extracted
at an arbitrary location on another machine. The load-time prefix
is computed relative to the file's location. Under that prefix the
file refers to all the other pieces (include, etc.) which exist at
a fixed location relative to BarConfig.cmake.
Right I did not realize that relative position should still be valid.
In fact I'm pretty sure you can break this if you mess-up with
absolute install destination, but if ones to that there is no point in using
this so...
Ok thank you (and David) for enlighting me on this.
--
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
Re: [cmake-developers] Making Config.cmake files easier to write
On Tuesday 14 February 2012, Alexander Neundorf wrote:
On Tuesday 14 February 2012, Yury G. Kudryashov wrote:
Alexander Neundorf wrote:
On Tuesday 14 February 2012, Yury G. Kudryashov wrote:
will substitute @PACKAGE_INCLUDE_INSTALL_DIR@ by ../../../include
and @PACKAGE_MYPKGDATA_INSTALL_DIR@ by ../../../share/mypkg (both
transformed to be relative to DESTINATION).
A problem I see here (and which we discussed already before on kde-
buildsystem) is the handling of the install() command.
I thought a bit about a syntax like this, which I would like:
configure_config_file(BarConfig.cmake.in BarConfig.cmake
INSTALL_DESTINATION ${CMAKECONFIG_INSTALL_DIR}
PATH_VARS INCLUDE_INSTALL_DIR DATA_INSTALL_DIR
EXPORT_FILE BarExport.cmake)
Why do you need EXPORT_FILE parameter? How can you use it? Include
automatically? Then you need VERSION_FILE parameter as well.
but this can't work, can it ?
In the BarConfig.cmake file there would still be either a
set(BAR_INCLUDE_DIR @INCLUDE_INSTALL_DIR@)
which would work for absolute paths, or a
set(BAR_INCLUDE_DIR ${SomePrefix}/@INCLUDE_INSTALL_DIR@)
which would work only for relative paths, but a simple set() cannot
work for both cases. Am I missing something ?
You'll have in BarConfig.cmake.in
set(BAR_INCLUDE_DIR @PACKAGE_HELPER_INCLUDE_INSTALL_DIR@)
After configure_config_file() you'll have
# At top
get_filename_component(_PKG_CURRENT_DIR ${CURRENT_LIST_FILE} PATH)
Just a tip: since 2.8.3 or so there is ${CMAKE_CURRENT_LIST_DIR}
get_filename_component(_PKG_PREFIX_PATH ${_PKG_CURRENT_DIR}/../../..
ABSOLUTE)
The ../../../ will be also calculated by the macro, using RELATIVE_PATH and
the DESTINATION parameter, right ?
#in place of your set()
set(BAR_INCLUDE_DIR ${_PKG_PREFIX_PATH}/include)
Do you have a working example ?
Not yet. I think about something like this (not tested).
foreach(var ${PACAKGE_HELPER_PATH_VARS})
if(NOT DEFINED ${var})
message(FATAL_ERROR ...)
else if(IS_ABSOLUTE ${${var}})
file(RELATIVE_PATH PACKAGE_HELPER_${var} ${CMAKE_INSTALL_PREFIX}
${${var}})
else()
set(PACKAGE_HELPER_${var} ${${var}})
endif()
endforeach()
It would be nice to make those PACKAGE_HELPER_* vars local to
configure_config_file() function.
If it's a function(), they are local automatically.
Also still not tested, but now it should have the right prefix:
foreach(var ${PACAKGE_HELPER_PATH_VARS})
if(NOT DEFINED ${var})
message(FATAL_ERROR ...)
else if(IS_ABSOLUTE ${${var}})
string(REPLACE ${CMAKE_INSTALL_PREFIX} \${_PKG_PREFIX_PATH}
PACKAGE_HELPER_${var} ${${var}}
else()
set(PACKAGE_HELPER_${var} ${${var}})
endif()
else()
set(PACKAGE_HELPER_${var} \${_PKG_PREFIX_PATH}/${${var}})
endif()
endforeach()
Ok, a working ConfigureConfigFile.cmake is attached, together with example
files, input and the configured output and the driving CMakeLists.txt.
The call now looks like this:
configure_config_file(BarConfig.cmake.in
${CMAKE_CURRENT_BINARY_DIR}/BarConfig.cmake
INSTALL_DESTINATION ${CMAKECONFIG_INSTALL_DIR}
PATH_VARS INCLUDE_INSTALL_DIR
BIN_INSTALL_DIR
FOO_INSTALL_DIR ...
)
and in the Config.cmake.in file you have to put:
@CONFIG_HELPER_DIRS_INIT@
set_and_check(BAR_INCLUDE_DIR @CONFIG_HELPER_INCLUDE_INSTALL_DIR@)
set(BAR_DATA_DIR@CONFIG_HELPER_DATA_INSTALL_DIR@)
The set_and_check() macro is provided by the @CONFIG_HELPER_DIRS_INIT@, it
sets the variable and checks that the given directory or file exists.
IMO it's a bit much macro magic.
I'll also try an alternative approach tomorrow.
Comments ?
Alex
# set the version of myself
set(BAR_VERSION_MAJOR @BAR_VERSION_MAJOR@)
set(BAR_VERSION_MINOR @BAR_VERSION_MINOR@)
set(BAR_VERSION_PATCH @BAR_VERSION_PATCH@)
set(BAR_VERSION ${BAR_VERSION_MAJOR}.${BAR_VERSION_MINOR}.${BAR_VERSION_PATCH} )
# get_filename_component(CONFIG_PREFIX_DIR
${CMAKE_CURRENT_LIST_DIR}/@CONFIG_RELATIVE_PATH@ ABSOLUTE)
@CONFIG_HELPER_DIRS_INIT@
set_and_check(BAR_INCLUDE_DIR @CONFIG_HELPER_INCLUDE_INSTALL_DIR@)
set_and_check(BAR_BIN_DIR @CONFIG_HELPER_BIN_INSTALL_DIR@)
set(BAR_DATA_DIR@CONFIG_HELPER_DATA_INSTALL_DIR@)
set(BAR_BAR_DIR @CONFIG_HELPER_BAR_INSTALL_DIR@)
set(BAR_FOO_DIR @CONFIG_HELPER_FOO_INSTALL_DIR@)
# what is my include directory
set(BAR_INCLUDES ${BAR_INCLUDE_DIR})
# import the exported targets
include(${CMAKE_CURRENT_LIST_DIR}/BarTargets.cmake)
# set the expected library variable
set(BAR_LIBRARIES bar )
cmake_minimum_required(VERSION 2.8.7)
project(Bar)
# the version number, needed for
# - the library version
# - version detection by
Re: [cmake-developers] Making Config.cmake files easier to write
On 2/15/2012 4:50 PM, Alexander Neundorf wrote:
Ok, a working ConfigureConfigFile.cmake is attached, together with example
files, input and the configured output and the driving CMakeLists.txt.
Nice!
Alternative name ideas:
CMakePackageHelper [1]
ConfigureCMakePackage
ConfigureCMakePackageFile
ConfigurePackage
ConfigurePackageFile
ConfigurePackageConfig
[1] Generic name for helper APIs so we can add more macros later.
In this case the macro can perhaps be called:
cmake_package_config
The call now looks like this:
configure_config_file(BarConfig.cmake.in
${CMAKE_CURRENT_BINARY_DIR}/BarConfig.cmake
INSTALL_DESTINATION ${CMAKECONFIG_INSTALL_DIR}
PATH_VARS INCLUDE_INSTALL_DIR
BIN_INSTALL_DIR
FOO_INSTALL_DIR ...
)
Good. Note that configure_file automatically treats a relative path
for the output file w.r.t. the build tree. Therefore the second arg
can be just BarConfig.cmake.
and in the Config.cmake.in file you have to put:
@CONFIG_HELPER_DIRS_INIT@
Good. Did you consider other prefixes? I'm okay with CONFIG_HELPER_
but I wonder if there is something better. Alternatively it could
be configured by an option to the macro.
set_and_check(BAR_INCLUDE_DIR @CONFIG_HELPER_INCLUDE_INSTALL_DIR@)
set(BAR_DATA_DIR@CONFIG_HELPER_DATA_INSTALL_DIR@)
The set_and_check() macro is provided by the @CONFIG_HELPER_DIRS_INIT@, it
sets the variable and checks that the given directory or file exists.
Okay. The set_and_check macro is perhaps overkill. I've never
done an explicit existence check on such directories in a package
configuration file. Let's not mix that into this feature yet.
I don't feel strongly about this though because a user can always
not use it.
IMO it's a bit much macro magic.
IMO it's simpler than your previous proposal. It is better for
all the magic to be at configuration time and not at load time.
Thanks,
-Brad
--
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
Re: [cmake-developers] Making Config.cmake files easier to write
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.
(2) The content of a relocatable BarConfig.cmake should not depend on
where it happened to be installed when the package was built.
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)
Another way to achieve the same result:
set(INCLUDE_INSTALL_DIR include) # relative
set(MYPKGDATA_INSTALL_DIR ${CMAKE_PREFIX_PATH}/share/mypkg) # absolute
cmake_package_config_for_install(Bar
DESTINATION lib/cmake/Bar
INPUT BarConfig-install.cmake.in
PATH_VARS
INCLUDE_INSTALL_DIR # interpreted as relative to install prefix
MYPKGDATA_INSTALL_DIR # absolute
)
will substitute @PACKAGE_INCLUDE_INSTALL_DIR@ by ../../../include and
@PACKAGE_MYPKGDATA_INSTALL_DIR@ by ../../../share/mypkg (both transformed
to be relative to DESTINATION).
The main advantage of this solution is that the relative path is calculated
only once (when package is installed), not every time Config.cmake file is
sourced. The main drawback is that one has to specify all required path
variables explicitly.
--
Yury G. Kudryashov,
mailto: ur...@mccme.ru
--
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
Re: [cmake-developers] Making Config.cmake files easier to write
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
Re: [cmake-developers] Making Config.cmake files easier to write
On 2/14/2012 1:26 PM, Alexander Neundorf wrote: 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. ...and we have to maintain compatibility in the module no matter what. It is much easier if the config files are standalone. (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). Leaving remnants of the original build/install location is a no-no for packagers. 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 ? See my discussion with Yuri in this thread. -Brad -- 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
Re: [cmake-developers] Making Config.cmake files easier to write
On Tuesday 14 February 2012, Yury G. Kudryashov wrote:
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.
(2) The content of a relocatable BarConfig.cmake should not depend on
where it happened to be installed when the package was built.
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)
Another way to achieve the same result:
set(INCLUDE_INSTALL_DIR include) # relative
set(MYPKGDATA_INSTALL_DIR ${CMAKE_PREFIX_PATH}/share/mypkg) # absolute
cmake_package_config_for_install(Bar
DESTINATION lib/cmake/Bar
INPUT BarConfig-install.cmake.in
PATH_VARS
INCLUDE_INSTALL_DIR # interpreted as relative to install prefix
MYPKGDATA_INSTALL_DIR # absolute
)
will substitute @PACKAGE_INCLUDE_INSTALL_DIR@ by ../../../include and
@PACKAGE_MYPKGDATA_INSTALL_DIR@ by ../../../share/mypkg (both transformed
to be relative to DESTINATION).
A problem I see here (and which we discussed already before on kde-
buildsystem) is the handling of the install() command.
The targets file and the version file have to be installed to the same
directory.
Currently I would do it like this:
configure_file(BarConfig.cmake.in BarConfig.cmake)
write_basic_config_version_file(BarConfigVersion.cmake
VERSION ${BAR_VERSION}
COMPATIBILITY AnyNewerVersion )
install(EXPORT BarExport DESTINATION ${CMAKECONFIG_INSTALL_DIR}
FILE BarTargets.cmake )
install(FILES BarConfig.cmake
BarConfigVersion.cmake
DESTINATION ${CMAKECONFIG_INSTALL_DIR} )
With the macro as suggested above, it would become:
write_basic_config_version_file(BarConfigVersion.cmake
VERSION ${BAR_VERSION}
COMPATIBILITY AnyNewerVersion )
cmake_package_config_for_install(Bar
DESTINATION ${CMAKECONFIG_INSTALL_DIR}
INPUT BarConfig.cmake.in
PATH_VARS INCLUDE_INSTALL_DIR DATA_INSTALL_DIR)
install(EXPORT BarExport DESTINATION ${CMAKECONFIG_INSTALL_DIR}
FILE BarTargets.cmake )
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/BarConfigVersion.cmake
DESTINATION ${CMAKECONFIG_INSTALL_DIR} )
What I don't like about this is that the three files which go into the same
directory are installed in three separate commands (install(FILES),
install(EXPORTS), cmake_package_config_for_install() ).
I thought a bit about a syntax like this, which I would like:
configure_config_file(BarConfig.cmake.in BarConfig.cmake
INSTALL_DESTINATION ${CMAKECONFIG_INSTALL_DIR}
PATH_VARS INCLUDE_INSTALL_DIR DATA_INSTALL_DIR
EXPORT_FILE BarExport.cmake)
write_basic_config_version_file(${CMAKE_CURRENT_BINARY_DIR}/BarConfigVersion.cmake
VERSION ${BAR_VERSION}
COMPATIBILITY AnyNewerVersion )
install(EXPORT BarExport DESTINATION ${CMAKECONFIG_INSTALL_DIR}
FILE BarTargets.cmake )
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/BarConfig.cmake
${CMAKE_CURRENT_BINARY_DIR}/BarConfigVersion.cmake
DESTINATION ${CMAKECONFIG_INSTALL_DIR} )
but this can't work, can it ?
In the BarConfig.cmake file there would still be either a
set(BAR_INCLUDE_DIR @INCLUDE_INSTALL_DIR@)
which would work for absolute paths, or a
set(BAR_INCLUDE_DIR ${SomePrefix}/@INCLUDE_INSTALL_DIR@)
which would work only for relative paths, but a simple set() cannot work for
both cases. Am I missing something ?
So I think there has to be a special macro to be used for setting those
variables in the Config.cmake file, which takes care of converting a relative
path into an absolute, and of potentially relocating an absolute path.
Do you have a working example ?
This week Thursday and Friday I'll have
Re: [cmake-developers] Making Config.cmake files easier to write
On Tuesday 14 February 2012, Brad King wrote: On 2/14/2012 1:26 PM, Alexander Neundorf wrote: 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. ...and we have to maintain compatibility in the module no matter what. It is much easier if the config files are standalone. Yes, that's a good point. Another option would be to install the included file along the Config.cmake file. (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). Leaving remnants of the original build/install location is a no-no for packagers. I don't know, we could ask them. Actually I don't think it would be a problem for a Linux distro packager, since in this case the original install destination will be also the final actual install location. I mean, they build the package for a place where it should be installed, and if you install the package via the normal package managers, this is where they will end up. Also, this wouldn't leave anything of the original build location in the file, only the intended install location. And this is what we do anyway since kdelibs 4.0. Right now we have code like this in KDE's installed files: ... if (NOT KDE4_INSTALL_DIR) set(KDE4_INSTALL_DIR /home/alex/installs/kdelibs) endif (NOT KDE4_INSTALL_DIR) set(KDE4_LIB_INSTALL_DIR /home/alex/installs/kdelibs/lib) set(KDE4_LIBEXEC_INSTALL_DIR /home/alex/installs/kdelibs/lib/kde4/libexec) set(KDE4_INCLUDE_INSTALL_DIR /home/alex/installs/kdelibs/include) ... and no packager ever complained that this would be a problem. 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 ? See my discussion with Yuri in this thread. I saw and replied, and can't really understand how I should write the BarConfig.cmake.in to make it work. Alternatively, Yuri suggested this in a thread on kde-buildsystem, there could be a macro which completely generates the Config.cmake file. This would get rid of a bunch of problems, like having to write complicated code in the Config.cmake file, but OTOH it would have to take quite a lot of parameters, e.g. how it should set up the LIBRARY variables from the exported targets, in which namespace they have been exported, etc. This would be a quite big macro. 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
Re: [cmake-developers] Making Config.cmake files easier to write
Alexander Neundorf wrote:
On Tuesday 14 February 2012, Yury G. Kudryashov wrote:
will substitute @PACKAGE_INCLUDE_INSTALL_DIR@ by ../../../include and
@PACKAGE_MYPKGDATA_INSTALL_DIR@ by ../../../share/mypkg (both
transformed to be relative to DESTINATION).
A problem I see here (and which we discussed already before on kde-
buildsystem) is the handling of the install() command.
I thought a bit about a syntax like this, which I would like:
configure_config_file(BarConfig.cmake.in BarConfig.cmake
INSTALL_DESTINATION ${CMAKECONFIG_INSTALL_DIR}
PATH_VARS INCLUDE_INSTALL_DIR DATA_INSTALL_DIR
EXPORT_FILE BarExport.cmake)
Why do you need EXPORT_FILE parameter? How can you use it? Include
automatically? Then you need VERSION_FILE parameter as well.
but this can't work, can it ?
In the BarConfig.cmake file there would still be either a
set(BAR_INCLUDE_DIR @INCLUDE_INSTALL_DIR@)
which would work for absolute paths, or a
set(BAR_INCLUDE_DIR ${SomePrefix}/@INCLUDE_INSTALL_DIR@)
which would work only for relative paths, but a simple set() cannot work
for both cases. Am I missing something ?
You'll have in BarConfig.cmake.in
set(BAR_INCLUDE_DIR @PACKAGE_HELPER_INCLUDE_INSTALL_DIR@)
After configure_config_file() you'll have
# At top
get_filename_component(_PKG_CURRENT_DIR ${CURRENT_LIST_FILE} PATH)
get_filename_component(_PKG_PREFIX_PATH ${_PKG_CURRENT_DIR}/../../..
ABSOLUTE)
#in place of your set()
set(BAR_INCLUDE_DIR ${_PKG_PREFIX_PATH}/include)
Do you have a working example ?
Not yet. I think about something like this (not tested).
foreach(var ${PACAKGE_HELPER_PATH_VARS})
if(NOT DEFINED ${var})
message(FATAL_ERROR ...)
else if(IS_ABSOLUTE ${${var}})
file(RELATIVE_PATH PACKAGE_HELPER_${var} ${CMAKE_INSTALL_PREFIX}
${${var}})
else()
set(PACKAGE_HELPER_${var} ${${var}})
endif()
endforeach()
It would be nice to make those PACKAGE_HELPER_* vars local to
configure_config_file() function.
--
Yury G. Kudryashov,
mailto: ur...@mccme.ru
--
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
Re: [cmake-developers] Making Config.cmake files easier to write
Alexander Neundorf wrote: On Tuesday 14 February 2012, Brad King wrote: Alternatively, Yuri suggested this in a thread on kde-buildsystem, there could be a macro which completely generates the Config.cmake file. This would get rid of a bunch of problems, like having to write complicated code in the Config.cmake file, but OTOH it would have to take quite a lot of parameters, e.g. how it should set up the LIBRARY variables from the exported targets, in which namespace they have been exported, etc. This would be a quite big macro. Now I think that it would require a lot of code for no real gain. A simple API would be write me a basic Config.cmake file for this export set but this would require a few changes in C++ code (i.e., turn export set into an object with properties like DESTINATION, FILE, NAMESPACE, TARGETS). -- Yury G. Kudryashov, mailto: ur...@mccme.ru -- 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
Re: [cmake-developers] Making Config.cmake files easier to write
On 2/14/2012 2:44 PM, Alexander Neundorf wrote:
In the BarConfig.cmake file there would still be either a
set(BAR_INCLUDE_DIR @INCLUDE_INSTALL_DIR@)
which would work for absolute paths, or a
set(BAR_INCLUDE_DIR ${SomePrefix}/@INCLUDE_INSTALL_DIR@)
which would work only for relative paths, but a simple set() cannot work for
both cases. Am I missing something ?
$ cat BarConfig.cmake.in
@PACKAGE_INIT@
set(BAR_INCLUDE_DIR @PACKAGE_INCLUDE_INSTALL_DIR@)
$ cat CMakeLists.txt
...
set(INCLUDE_INSTALL_DIR ...)
cmake_package_config_for_install(Bar
DESTINATION ${CMAKECONFIG_INSTALL_DIR}
PATH_VARS INCLUDE_INSTALL_DIR)
The macro should check the value of INSTALL_INCLUDE_DIR.
Relative case:
$ cat BarConfig.cmake
get_filename_component(BAR_INSTALL_PREFIX ${CMAKE_CURRENT_LIST_FILE} PATH)
get_filename_component(BAR_INSTALL_PREFIX ${BAR_INSTALL_PREFIX} PATH)
get_filename_component(BAR_INSTALL_PREFIX ${BAR_INSTALL_PREFIX} PATH)
# ... repeated based on depth of BarConfig install location
set(BAR_INCLUDE_DIR ${BAR_INSTALL_PREFIX}/include/bar)
Absolute case when value happens to be under ${CMAKE_INSTALL_PREFIX}:
$ cat BarConfig.cmake
get_filename_component(BAR_INSTALL_PREFIX ${CMAKE_CURRENT_LIST_FILE} PATH)
get_filename_component(BAR_INSTALL_PREFIX ${BAR_INSTALL_PREFIX} PATH)
get_filename_component(BAR_INSTALL_PREFIX ${BAR_INSTALL_PREFIX} PATH)
# ... repeated based on depth of BarConfig install location
set(BAR_INCLUDE_DIR ${BAR_INSTALL_PREFIX}/include/bar)
Outside absolute case:
$ cat BarConfig.cmake
get_filename_component(BAR_INSTALL_PREFIX ${CMAKE_CURRENT_LIST_FILE} PATH)
get_filename_component(BAR_INSTALL_PREFIX ${BAR_INSTALL_PREFIX} PATH)
get_filename_component(BAR_INSTALL_PREFIX ${BAR_INSTALL_PREFIX} PATH)
# ... repeated based on depth of BarConfig install location
set(BAR_INCLUDE_DIR /somewhere/include/bar)
The replacement for @PACKAGE_INIT@ is always the same, and can handle
computing BAR_INSTALL_PREFIX at load time.
In all cases the macro replaces @PACKAGE_INCLUDE_INSTALL_DIR@ with
something that it knows how to compute at configuration time. It
can replace it with a literal ${BAR_INSTALL_PREFIX} in the relative
and relocatable cases so that the proper prefix appears at load time.
-Brad
P.S. Yury, I apologize for spelling your name incorrectly in my other post.
--
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
