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
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.
#
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
34 matches
Mail list logo