Re: [cmake-developers] RFC: standard (and not so standard) install dirs
On 1/10/2012 4:16 PM, Alexander Neundorf wrote:
These variables are defined in FindKDE4Internal.cmake, so any package doing
find_package(KDE4)
can make use of these variables for installing its stuff.
If I understand correctly there will no longer be a single base package that
every KDE project can find to get these things. On the other hand, you want
to have a standard set of install variables without duplicating code. These
goals are at odds. Why not have a single base package just for CMake files:
find_package(KDE4CMake)
? It would be a very lightweight module but could totally solve this problem
and provide a central place for common KDE CMake macros/functions and such.
Otherwise even if we solve the problem at hand I expect you'll run into more
trouble looking for places to put common pieces.
That said, here are my comments assuming you don't go with the above.
With the ongoing modularization of kdelibs we'd like to standardize this a bit
more and using a more generic, non KDE-specific solution.
I'm not sure how it can be non-KDE because it uses the set of variables
that KDE needs. Sure, there is some overlap with similar needs for other
projects (GNU), but that does not mean KDE can use a non-KDE set. That's
why the case of the DBUS and other custom variables kept coming up in your
original post.
Now since a few releases CMake has GNUInstallDirs.cmake.
This module serves a similar purpose. Unfortunately it introduced different
names for these variables, but ok.
That's why we included GNU in the name of the module. It's the set
that GNU defines, which is not necessarily the set that KDE uses.
Where should the missing variables be added ?
Should they simply all be added to GNUInstallDirs.cmake ?
Does it make sense to gather all kinds of install dir variables in one place ?
Just like GNU defines a standard set of variables for their projects, KDE
appears to do so as well. We included the GNUInstallDirs module to make
it easy to convert projects following the GNU layout to CMake. I see no
reason we couldn't do the same thing for projects following the KDE layout.
Why not create a KDEInstallDirs.cmake that comes with CMake? It wouldn't
actually contain any KDE-specific code, just a documented layout standard
that could be used by KDE project or outside projects that like the KDE
install layout. OTOH, if it needs to initialize paths like lib/kde4/libexec
then that is very specific to KDE and would not belong in a generic interface.
Example: let's say we (KDE) switch to using GNUInstallDirs.cmake, and every
KDE application should set CMAKE_INSTALL_LIBEXECDIR to
${LIB_INSTALL_DIR}/kde4/libexec/ instead of libexec/.
This would be necessary to make those projects work, so it would be very
desirable that some base package would install some file into some install
prefix which sets CMAKE_INSTALL_LIBEXECDIR accordingly, and so the using
project would get its install dir variable initialized correctly
automatically.
Why can't the base package be responsible for defining the install locations
in the first place, as I propose at the top of this response?
And there is one additional question I have:
Is it actually necessary to make all those install dir variable editable for
the user ?
The GNUInstallDirs is intended to follow the GNU layout rules to help projects
coming from autotools to CMake use the same layout. It is intended that the
destinations be changeable by packagers looking to conform to their distro
layout.
It comes with a cost, especially when we want people to start installing
FooConfig.cmake files.
[snip]
To support the fully flexible version, the developer must calculate the
relative path from the configured CONFIG_INSTALL_DIR (where the Config.cmake
file goes) to the configured INCLUDE_INSTALL_DIR.
It's not too hard. See ITK for example:
http://itk.org/gitweb?p=ITK.git;a=blob;f=CMakeLists.txt;hb=v4.0.0#l558
do you have suggestions how to make the code needed in the
Config.cmake files easier ?
I've done this for a few projects that allow such destinations to be changed.
If one destination is a full path then it can just be used as-is. If it is
a relative path then I start by computing the installation prefix based on
the installation depth of the Config.cmake file using get_filename_component.
Then I add on the other relative destination.
I don't think the case that the Config.cmake install destination is absolute
and the others are relative to an installation prefix is important. I see
no real-world use case to do things that way.
-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
[cmake-developers] Dashboard issues with ExternalProject (untar bz2 not working?)
ExternalProject is failing in a few places: http://www.cdash.org/CDash/testSummary.php?project=1name=ExternalProjectdate=2012-01-11 Seems to be an issue with bz2 untar: CMake Error: Problem with archive_read_open_file(): Child process exited with status 254 CMake Error: Problem extracting tar: /mnt/kitware/Dashboards/My Tests-HP-UXUB.11.2ia64-aCC/CMake/Tests/ExternalProject/Step1.tar.bz2 -Bill -- 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] Dashboard issues with ExternalProject (untar bz2 not working?)
On 1/11/2012 12:04 PM, Rolf Eike Beer wrote: That was me. I pushed a topic to stage yesterday for review that improved FindBZip2.cmake to detect the debug library on Windows and handle both optimized and debug variants. CMake preloads the BZIP2_LIBRARIES variable with cmbzip2, which currently is ignored in that new thing. The top-level CMakeLists.txt file in CMake needs to pre-load BZIP2_* with whatever is needed to convince find_package(BZIP2) to use the CMake-built cmbzip2 library. If you're changing the Find module for it then what needs to be pre-loaded may depend on which version of CMake is used to configure the build of CMake. It's a bit tricky. -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] Dashboard issues with ExternalProject (untar bz2 not working?)
Am Mittwoch 11 Januar 2012, 13:24:42 schrieben Sie: On 1/11/2012 12:04 PM, Rolf Eike Beer wrote: That was me. I pushed a topic to stage yesterday for review that improved FindBZip2.cmake to detect the debug library on Windows and handle both optimized and debug variants. CMake preloads the BZIP2_LIBRARIES variable with cmbzip2, which currently is ignored in that new thing. The top-level CMakeLists.txt file in CMake needs to pre-load BZIP2_* with whatever is needed to convince find_package(BZIP2) to use the CMake-built cmbzip2 library. If you're changing the Find module for it then what needs to be pre-loaded may depend on which version of CMake is used to configure the build of CMake. It's a bit tricky. I pushed an updated version to topic improve-findbzip2, hopefully that would do it. Does this look sane? Should I merge it into next or revert the last patch on next? Eike signature.asc Description: This is a digitally signed message part. -- 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] FindBZip2 (was: Dashboard issues with ExternalProject)
On 1/11/2012 1:31 PM, Rolf Eike Beer wrote:
Am Mittwoch 11 Januar 2012, 13:24:42 schrieben Sie:
The top-level CMakeLists.txt file in CMake needs to pre-load BZIP2_*
with whatever is needed to convince find_package(BZIP2) to use the
CMake-built cmbzip2 library. If you're changing the Find module for
it then what needs to be pre-loaded may depend on which version of
CMake is used to configure the build of CMake. It's a bit tricky.
I pushed an updated version to topic improve-findbzip2, hopefully that would
do it. Does this look sane?
Since you're changing the way that module looks for libraries you should
also fix up some historical wrongness in it. The Module/readme.txt file
explains that BZIP2_LIBRARIES should not be a cache variable. Instead
it should be a normal variable that collects the results from other
single-library searches. Ideally the module (with config support) should
offer these cache entries for users to set:
BZIP2_LIBRARY_RELEASE
BZIP2_LIBRARY_DEBUG
and the output should all be in a single
set(BZIP2_LIBRARIES optimized ${BZIP2_LIBRARY_RELEASE}
debug ${BZIP2_LIBRARY_DEBUG})
cmake variable (not cached) whose content is adjusted for various
combinations of availability of each piece. For compatibility you need
to honor BZIP2_LIBRARIES if it is set before the module is loaded, but you
do not need to cache it.
Should I merge it into next or revert the last patch on next?
Which is the last patch?
-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] FindBZip2 (was: Dashboard issues with ExternalProject)
Am Mittwoch, 11. Januar 2012, 15:32:47 schrieb Brad King:
On 1/11/2012 1:31 PM, Rolf Eike Beer wrote:
Am Mittwoch 11 Januar 2012, 13:24:42 schrieben Sie:
The top-level CMakeLists.txt file in CMake needs to pre-load BZIP2_*
with whatever is needed to convince find_package(BZIP2) to use the
CMake-built cmbzip2 library. If you're changing the Find module for
it then what needs to be pre-loaded may depend on which version of
CMake is used to configure the build of CMake. It's a bit tricky.
I pushed an updated version to topic improve-findbzip2, hopefully that
would do it. Does this look sane?
Since you're changing the way that module looks for libraries you should
also fix up some historical wrongness in it. The Module/readme.txt file
explains that BZIP2_LIBRARIES should not be a cache variable. Instead
it should be a normal variable that collects the results from other
single-library searches. Ideally the module (with config support) should
offer these cache entries for users to set:
BZIP2_LIBRARY_RELEASE
BZIP2_LIBRARY_DEBUG
and the output should all be in a single
set(BZIP2_LIBRARIES optimized ${BZIP2_LIBRARY_RELEASE}
debug ${BZIP2_LIBRARY_DEBUG})
That's the way we currently have in next.
cmake variable (not cached) whose content is adjusted for various
combinations of availability of each piece. For compatibility you need
to honor BZIP2_LIBRARIES if it is set before the module is loaded, but you
do not need to cache it.
Should I merge it into next or revert the last patch on next?
Which is the last patch?
96ae584
The current problem is that CMake set BZIP2_LIBRARIES which is not cached. So
if a user is used to set BZIP2_LIBRARIES this would only work the first time
now. Since the variable is not cached it would eventually get lost and the
user suddenly has an unexpected build failure. Or do I get something entirely
wrong.
Eike
signature.asc
Description: This is a digitally signed message part.
--
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] FindBZip2 (was: Dashboard issues with ExternalProject)
On Wednesday 11 January 2012, Rolf Eike Beer wrote:
Am Mittwoch, 11. Januar 2012, 15:32:47 schrieb Brad King:
On 1/11/2012 1:31 PM, Rolf Eike Beer wrote:
Am Mittwoch 11 Januar 2012, 13:24:42 schrieben Sie:
The top-level CMakeLists.txt file in CMake needs to pre-load BZIP2_*
with whatever is needed to convince find_package(BZIP2) to use the
CMake-built cmbzip2 library. If you're changing the Find module for
it then what needs to be pre-loaded may depend on which version of
CMake is used to configure the build of CMake. It's a bit tricky.
I pushed an updated version to topic improve-findbzip2, hopefully that
would do it. Does this look sane?
Since you're changing the way that module looks for libraries you should
also fix up some historical wrongness in it. The Module/readme.txt file
explains that BZIP2_LIBRARIES should not be a cache variable. Instead
it should be a normal variable that collects the results from other
single-library searches. Ideally the module (with config support) should
offer these cache entries for users to set:
BZIP2_LIBRARY_RELEASE
BZIP2_LIBRARY_DEBUG
and the output should all be in a single
set(BZIP2_LIBRARIES optimized ${BZIP2_LIBRARY_RELEASE}
debug ${BZIP2_LIBRARY_DEBUG})
That's the way we currently have in next.
How about creating an imported target and use ${BZIP2_LIBRARY_RELEASE} and
${BZIP2_LIBRARY_DEBUG} to set the respective LOCATION properties ?
Like
add_library(ImportedLibrary::Bzip2 IMPORTED )
set_target_properties(ImportedLibrary::Bzip2
PROPERTIES IMPORTED_CONFIGS DEBUG;RELEASE
LOCATION_DEBUG ${BZIP2_LIBRARY_DEBUG}
LOCATION_RELEASE ${BZIP2_LIBRARY_RELEASE} )
set(BZIP2_LIBRARIES ImportedLibrary::Bzip2 )
There is a small source incompatiblity, in the case that somebody assumes
that BZIP2_LIBRARIES contains a file path, but beside that, it's a good thing
and makes stuff work better on Windows (since if another project installs an
exported targets file, and if those targets have been linked against the
installed bzip2-target, they will reference the target in their export file,
which will be found by FindBZip2.cmake at cmake-time of a using project on the
end system, instead of depending on the full fixed path to libbzip2 on the
developer system).
FindQt4.cmake does already create imported targets for the libs it finds.
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] RFC: standard (and not so standard) install dirs
On Wednesday 11 January 2012, Brad King wrote: ... To support the fully flexible version, the developer must calculate the relative path from the configured CONFIG_INSTALL_DIR (where the Config.cmake file goes) to the configured INCLUDE_INSTALL_DIR. It's not too hard. See ITK for example: Depends on the definition of too ;-) I'll see whether I can come up with some macro or helper file to make it easier. http://itk.org/gitweb?p=ITK.git;a=blob;f=CMakeLists.txt;hb=v4.0.0#l558 do you have suggestions how to make the code needed in the Config.cmake files easier ? I've done this for a few projects that allow such destinations to be changed. If one destination is a full path then it can just be used as-is. If it is a relative path then I start by computing the installation prefix based on the installation depth of the Config.cmake file using get_filename_component. Then I add on the other relative destination. Yes, that's basically what I do here too: https://projects.kde.org/projects/kde/kdeexamples/repository/revisions/master/show/buildsystem/HowToInstallALibrary I don't think the case that the Config.cmake install destination is absolute and the others are relative to an installation prefix is important. I see no real-world use case to do things that way. Thanks for taking your time to read and respond to this :-) 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] FindBZip2 (was: Dashboard issues with ExternalProject)
Am Mittwoch 11 Januar 2012, 22:03:52 schrieb Rolf Eike Beer:
Am Mittwoch, 11. Januar 2012, 15:32:47 schrieb Brad King:
On 1/11/2012 1:31 PM, Rolf Eike Beer wrote:
Am Mittwoch 11 Januar 2012, 13:24:42 schrieben Sie:
The top-level CMakeLists.txt file in CMake needs to pre-load
BZIP2_*
with whatever is needed to convince find_package(BZIP2) to use the
CMake-built cmbzip2 library. If you're changing the Find module
for
it then what needs to be pre-loaded may depend on which version of
CMake is used to configure the build of CMake. It's a bit tricky.
I pushed an updated version to topic improve-findbzip2, hopefully
that
would do it. Does this look sane?
Since you're changing the way that module looks for libraries you should
also fix up some historical wrongness in it. The Module/readme.txt file
explains that BZIP2_LIBRARIES should not be a cache variable. Instead
it should be a normal variable that collects the results from other
single-library searches. Ideally the module (with config support)
should
offer these cache entries for users to set:
BZIP2_LIBRARY_RELEASE
BZIP2_LIBRARY_DEBUG
and the output should all be in a single
set(BZIP2_LIBRARIES optimized ${BZIP2_LIBRARY_RELEASE}
debug
${BZIP2_LIBRARY_DEB
UG})
That's the way we currently have in next.
cmake variable (not cached) whose content is adjusted for various
combinations of availability of each piece. For compatibility you need
to honor BZIP2_LIBRARIES if it is set before the module is loaded, but
you do not need to cache it.
Should I merge it into next or revert the last patch on next?
Which is the last patch?
96ae584
The current problem is that CMake set BZIP2_LIBRARIES which is not cached.
So if a user is used to set BZIP2_LIBRARIES this would only work the first
time now. Since the variable is not cached it would eventually get lost and
the user suddenly has an unexpected build failure. Or do I get something
entirely wrong.
I decided to give this another try before reverting it. After I hopefully
fixed up my messed up local branch I now pushed a fixed version upstream that
hopefully will do the right thing (tm). If not I'll wipe all this tomorrow.
Eike
signature.asc
Description: This is a digitally signed message part.
--
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
