Re: [cmake-developers] FindPackageCheckArchLinuxSymlinks branch on stage
On Friday 08 March 2013, Brad King wrote: On 1/25/2013 8:54 AM, Brad King wrote: On 01/25/2013 05:14 AM, Stephen Kelly wrote: Are INSTALL(EXPORT)ed files affected at all by this? Do they need to be? Yes, since they compute paths relative to their location in order to be relocatable. The code that generates them may need to be made aware of this. Please try out this change: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0c727b90 Looks good, will give it a try. I haven't checked yet whether there are any issues with cpack, since it has two different modes, a DESTDIR one and another one. I will have a look. Thanks :-) 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] FindPackageCheckArchLinuxSymlinks branch on stage
Alexander Neundorf wrote:
It looks like you merged your patch to next, but didn't account for this
part. I recommend doing something similar to what you did for the macro
to manipulate the _IMPORT_PREFIX in export files. Wait for my
fix-relocatable- include-dirs topic to be merged first though.
I thought that's your part, since you're working on the target stuff a lot
:-)
That doesn't mean anything I'm afraid. The patches I wrote had nothing to do
with this, and I don't have the energy for this task.
I had another look at your patch and noticed that $ENV{DESTDIR} is not
handled. Should it be?
Thanks,
Steve.
--
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] FindPackageCheckArchLinuxSymlinks branch on stage
On 02/01/2013 09:37 AM, Stephen Kelly wrote:
I had another look at your patch and noticed that $ENV{DESTDIR} is not
handled. Should it be?
No, the decision is about where the files expect themselves to be when
they are loaded in use. DESTDIR is only about packaging.
-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] FindPackageCheckArchLinuxSymlinks branch on stage
Alexander Neundorf wrote: On Friday 25 January 2013, Brad King wrote: On 01/25/2013 03:24 PM, Alexander Neundorf wrote: On Friday 25 January 2013, Brad King wrote: On 01/25/2013 05:14 AM, Stephen Kelly wrote: Are INSTALL(EXPORT)ed files affected at all by this? Do they need to be? Yes, since they compute paths relative to their location in order to be relocatable. The code that generates them may need to be made aware of this. I don't think so. These file should be installed into lib/, so even if lib/ is a symlink, the relative path from the targets file to the library does not cross the symlink. What if an executable target installed to bin/ is exported in the targets file? Right. It looks like you merged your patch to next, but didn't account for this part. I recommend doing something similar to what you did for the macro to manipulate the _IMPORT_PREFIX in export files. Wait for my fix-relocatable- include-dirs topic to be merged first though. Thanks, Steve. -- 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] FindPackageCheckArchLinuxSymlinks branch on stage
On Monday 28 January 2013, Stephen Kelly wrote: Alexander Neundorf wrote: On Friday 25 January 2013, Brad King wrote: On 01/25/2013 03:24 PM, Alexander Neundorf wrote: On Friday 25 January 2013, Brad King wrote: On 01/25/2013 05:14 AM, Stephen Kelly wrote: Are INSTALL(EXPORT)ed files affected at all by this? Do they need to be? Yes, since they compute paths relative to their location in order to be relocatable. The code that generates them may need to be made aware of this. I don't think so. These file should be installed into lib/, so even if lib/ is a symlink, the relative path from the targets file to the library does not cross the symlink. What if an executable target installed to bin/ is exported in the targets file? Right. It looks like you merged your patch to next, but didn't account for this part. I recommend doing something similar to what you did for the macro to manipulate the _IMPORT_PREFIX in export files. Wait for my fix-relocatable- include-dirs topic to be merged first though. I thought that's your part, since you're working on the target stuff a lot :-) 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] FindPackageCheckArchLinuxSymlinks branch on stage
Alexander Neundorf wrote: The CONFIGURE_PACKAGE_CONFIG_FILE() macro could check its INSTALL_DESTINATION argument, whether it is /lib[64]/ or /usr/lib[64]/ and use full paths in that case. I'll play around a bit with the macro. There is now the PackageConfigHelper_UsrMove branch on stage. Are INSTALL(EXPORT)ed files affected at all by this? Do they need to be? Thanks, Steve. -- 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] FindPackageCheckArchLinuxSymlinks branch on stage
On 01/25/2013 05:14 AM, Stephen Kelly wrote: Alexander Neundorf wrote: The CONFIGURE_PACKAGE_CONFIG_FILE() macro could check its INSTALL_DESTINATION argument, whether it is /lib[64]/ or /usr/lib[64]/ and use full paths in that case. I'll play around a bit with the macro. There is now the PackageConfigHelper_UsrMove branch on stage. Are INSTALL(EXPORT)ed files affected at all by this? Do they need to be? Yes, since they compute paths relative to their location in order to be relocatable. The code that generates them may need to be made aware of this. -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] FindPackageCheckArchLinuxSymlinks branch on stage
On Friday 25 January 2013, Brad King wrote: On 01/25/2013 05:14 AM, Stephen Kelly wrote: Alexander Neundorf wrote: The CONFIGURE_PACKAGE_CONFIG_FILE() macro could check its INSTALL_DESTINATION argument, whether it is /lib[64]/ or /usr/lib[64]/ and use full paths in that case. I'll play around a bit with the macro. There is now the PackageConfigHelper_UsrMove branch on stage. Are INSTALL(EXPORT)ed files affected at all by this? Do they need to be? Yes, since they compute paths relative to their location in order to be relocatable. The code that generates them may need to be made aware of this. I don't think so. These file should be installed into lib/, so even if lib/ is a symlink, the relative path from the targets file to the library does not cross the symlink. If it is installed into share/ (which it IMO should not), there is no symlink involved (with /usr-move). 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] FindPackageCheckArchLinuxSymlinks branch on stage
On 01/25/2013 03:24 PM, Alexander Neundorf wrote: On Friday 25 January 2013, Brad King wrote: On 01/25/2013 05:14 AM, Stephen Kelly wrote: Are INSTALL(EXPORT)ed files affected at all by this? Do they need to be? Yes, since they compute paths relative to their location in order to be relocatable. The code that generates them may need to be made aware of this. I don't think so. These file should be installed into lib/, so even if lib/ is a symlink, the relative path from the targets file to the library does not cross the symlink. What if an executable target installed to bin/ is exported in the targets file? -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] FindPackageCheckArchLinuxSymlinks branch on stage
On Friday 25 January 2013, Brad King wrote: On 01/25/2013 03:24 PM, Alexander Neundorf wrote: On Friday 25 January 2013, Brad King wrote: On 01/25/2013 05:14 AM, Stephen Kelly wrote: Are INSTALL(EXPORT)ed files affected at all by this? Do they need to be? Yes, since they compute paths relative to their location in order to be relocatable. The code that generates them may need to be made aware of this. I don't think so. These file should be installed into lib/, so even if lib/ is a symlink, the relative path from the targets file to the library does not cross the symlink. What if an executable target installed to bin/ is exported in the targets file? Right. 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] FindPackageCheckArchLinuxSymlinks branch on stage
On Thursday 24 January 2013, Brad King wrote: On 01/24/2013 03:40 PM, Alexander Neundorf wrote: There is now the PackageConfigHelper_UsrMove branch on stage. If the Config.cmake will be installed to /lib(64) or /usr/lib(64), it will use full absolute paths. I like that approach. It automatically distinguishes between the two common use cases with no special settings. Normally a binary tarball distribution would be installed with a prefix like .../$package-$version into a use home directory so that $package-$version/ would be at the top of the tarball. In that case your new logic will still use the relative paths. Nice! One note: this checks is done at cmake time of the package in question, not at install or at usage time (which would be the best time to do it). I guess this does not work as it should if the install location is changed by giving a modified CMAKE_INSTALL_PREFIX to cmake_install.cmake . But it's the best I could come up with so far. 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] FindPackageCheckArchLinuxSymlinks branch on stage
On 01/24/2013 12:39 PM, Alexander Neundorf wrote: Also, it could have been installed into the symlink, but be found via the non- symlink path. Right, it is not possible to handle installing into a symlink because we cannot know that when computing paths ahead of time. The two competing goals are: * Relocatable package. This is for binary tarball distributions and we can assume there will be no symlink mess because we control the tarball. If someone extracts it in a system prefix then they are on their own. * Distro-maintained package. This has a fixed install path and should simply use full paths. I do not think we should try to handle cross-prefix symlinks at the same time as relocatable packages. The remaining issue is how to know which one the current build wants. Ideas? -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] FindPackageCheckArchLinuxSymlinks branch on stage
On Thursday 24 January 2013, Brad King wrote: On 01/24/2013 12:39 PM, Alexander Neundorf wrote: Also, it could have been installed into the symlink, but be found via the non- symlink path. Right, it is not possible to handle installing into a symlink because we cannot know that when computing paths ahead of time. The two competing goals are: * Relocatable package. This is for binary tarball distributions and we can assume there will be no symlink mess because we control the tarball. If someone extracts it in a system prefix then they are on their own. * Distro-maintained package. This has a fixed install path and should simply use full paths. I do not think we should try to handle cross-prefix symlinks at the same time as relocatable packages. The remaining issue is how to know which one the current build wants. Ideas? Symlinks could appear in any prefix. But do we have to care about that, or is it good enough if we try to make the /lib[64]/ symlinks related to the ongoing /usr-move work ? Gentoo just wants to symlink files, which would be ok for cmake: http://wiki.gentoo.org/wiki//usr_move Fedora, ArchLinux, Mageia symlink the directories: https://fedoraproject.org/wiki/Features/UsrMove https://wiki.mageia.org/en/Feature:UsrMove https://wiki.archlinux.org/index.php/DeveloperWiki:UsrMove The CONFIGURE_PACKAGE_CONFIG_FILE() macro could check its INSTALL_DESTINATION argument, whether it is /lib[64]/ or /usr/lib[64]/ and use full paths in that case. I'll play around a bit with the 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] FindPackageCheckArchLinuxSymlinks branch on stage
On 01/24/2013 03:40 PM, Alexander Neundorf wrote: There is now the PackageConfigHelper_UsrMove branch on stage. If the Config.cmake will be installed to /lib(64) or /usr/lib(64), it will use full absolute paths. I like that approach. It automatically distinguishes between the two common use cases with no special settings. Normally a binary tarball distribution would be installed with a prefix like .../$package-$version into a use home directory so that $package-$version/ would be at the top of the tarball. In that case your new logic will still use the relative paths. Nice! 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] FindPackageCheckArchLinuxSymlinks branch on stage
On 1/21/2013 4:49 PM, Alexander Neundorf wrote:
It makes cmake warn if /lib64/ is a symbolic link to /usr/lib/ and a
Config.cmake file has been found in one of both (since any relative directory
references may be wrong then), see the General Config.cmake file issue on
ArchLinux thread here from November.
A package configuration file can know the path in which it was
installed under the prefix rather than just the number of path
components below the prefix. Rather than using ../.. or
stripping path components to get back the original prefix,
we can actually *compare* the suffix part.
Say we install FooConfig.cmake to prefix/lib/cmake/foo.
The file can check if ${CMAKE_CURRENT_LIST_FILE} sits in a
path ending in /lib/cmake/foo. If so, then the part before
that is the prefix. If not, then we likely have a symlink.
Try resolving symlinks and then checking whether the path
now ends in /lib/cmake/foo. If so, we now have a prefix.
If not, then someone has fiddled with the layout since the
installation.
-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] FindPackageCheckArchLinuxSymlinks branch on stage
On Tuesday 22 January 2013, Stephen Kelly wrote: Alexander Neundorf wrote: Hi, I pushed the FindPackageCheckArchLinuxSymlinks branch to stage, haven't merged it yet. Hi, A conversation a few weeks ago on IRC hinted that gentoo are doing the same thing now/soon. I just searched and found http://wiki.gentoo.org/wiki//usr_move which also links to http://fedoraproject.org/wiki/Features/UsrMove which is talking about symlinking the root directories into /usr, including the lib64 directory. Given that, at least your method naming could be made more generic (ie CheckArchLinuxSymlinks is not a good name). You wrote a comment 'the 64/ directories are searched before the other directories'. Is that a cmake feature? Can those directories which are symlinks be excepted from that priority? Does that make any sense? Will we get problems arising from the non-64 directories? Is CMake searching in /lib* before /usr/lib/* ? Should that be changed? AFAIK the lib64 dirs are searched first, then the versions without 64 appended. Which has the effect that /lib64/ is searched before /usr/lib/. OTOH if somebody installs a package to /, the config file will be in /lib/cmake/foo/FooConfig.cmake, and the include dir may be /usr/include/foo/. But this config file will then be found as /usr/lib/cmake/foo/FooConfig.cmake, and it will reference the include dir as /usr/usr/include/foo/ I think. So I think changing the search order does not help. If searching one way, one case fails, if searching the other way, the other case fails. If lib/ (or lib64/) is a symlink from one prefix into another prefix, and not all subdirs are symlinked, it will fail. I think this is all a mess for cmake's config files, as long as they try to be relocatable. Should we just forget about relocatable Config.cmake files on UNIX (excluding OSX) systems ? It makes cmake warn if /lib64/ is a symbolic link to /usr/lib/ and a Config.cmake file has been found in one of both (since any relative directory references may be wrong then), see the General Config.cmake file issue on ArchLinux thread here from November. Given that Andrea Scarpino said that the /include dir does not exist, I don't see why you check for it in your patch. Maybe somebody adds it in the future... Mostly to make visible what should be there so that it works. Checking whether /usr/lib is a symlink to /lib64 was one of the ideas we came up with, but I still think I prefer a more generic symlink check somehow, but I'm not about to dig into that at the moment. I'm not sure more generic is necessary. Also I don't see a way how to fix it actually. 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] FindPackageCheckArchLinuxSymlinks branch on stage
Alexander Neundorf wrote: I think this is all a mess for cmake's config files, as long as they try to be relocatable. Should we just forget about relocatable Config.cmake files on UNIX (excluding OSX) systems ? Maybe it would be better to build some awareness into CMake of which platforms are symlinking like this, and what they are symlinking. That way, if a Config file is found in /lib64/lib/cmake/FooConfig.cmake, cmake would be able to 'switch' to use the non-symlink, which would make the relative paths correct, as long as the actual install was all into non-symlinks. Something like this in Linux.cmake (partly pseudocode): if (ARCHLINUX OR FEDORA18) set(PLATFORM_SYMLINK_PAIRS /lib64 /usr/lib64 /bin /usr/bin # For illustration only. Config files don't get found below /bin, so this doesn't matter. ) endif() Would something like that work? It might not help in the case of someone installing to /opt/foo and then putting *that* in their CMAKE_PREFIX_PATH, but that's a bug the user is creating in their own environment anyway, not a platform quirk for us to handle, so it doesn't matter. It makes cmake warn if /lib64/ is a symbolic link to /usr/lib/ and a Config.cmake file has been found in one of both (since any relative directory references may be wrong then), see the General Config.cmake file issue on ArchLinux thread here from November. Given that Andrea Scarpino said that the /include dir does not exist, I don't see why you check for it in your patch. Maybe somebody adds it in the future... If that matters (I don't believe it does) you should add at least everything else which is in GNUInstallDirs.cmake. Thanks, Steve. -- 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] FindPackageCheckArchLinuxSymlinks branch on stage
On Tuesday 22 January 2013, Stephen Kelly wrote: Alexander Neundorf wrote: I think this is all a mess for cmake's config files, as long as they try to be relocatable. Should we just forget about relocatable Config.cmake files on UNIX (excluding OSX) systems ? Maybe it would be better to build some awareness into CMake of which platforms are symlinking like this, and what they are symlinking. That way, if a Config file is found in /lib64/lib/cmake/FooConfig.cmake, cmake would be able to 'switch' to use the non-symlink, which would make the relative paths correct, as long as the actual install was all into non-symlinks. Yes, but as you say, only as long as the actual install was all into non- symlinks. So what do we do about a package which installs into /lib64/, /bin/ and /usr/include/ ? Here the found path in /lib64/lib/cmake/FooConfig.cmake would be the correct one, without the switching. Maybe somewhere some logic could be added, so that if a config file is found in one of the two directories which are symlink pairs (as you suggest below), then in some way get the used CMAKE_INSTALL_PREFIX from the config (or version) file, and if this is the directory where it has been found, it is accepted, if it is the other symlinked directory, it is skipped, if it is none of both, it is accepted too. This might work in many cases, but doesn't feel like a good solution. Is there a way to keep cmake from installing into symlinked lib/ dirs ? If, then find_package() could skip (known) lib/ dirs which are symlinks. But, if somebody installs with DESTDIR, cmake has no idea whether lib/ is a symlink or a real directory in the actual file system. Except if, as you suggest below, cmake knows which directories are symlinks. Then, install() could error out if the destination is such a known symlinked dir, and find_package() could skip those symlinked dirs when searching. Would that be safe ? Hmm, this would fail if I let's say create an rpm on SUSE (without symlinks) and then install it on Fedora (with symlinks). Or, as I already said, on UNIX systems just put full absolute paths in the Config.cmake files, then this is no issue (but the package can't be installed to another place). Something like this in Linux.cmake (partly pseudocode): if (ARCHLINUX OR FEDORA18) set(PLATFORM_SYMLINK_PAIRS /lib64 /usr/lib64 /bin /usr/bin # For illustration only. Config files don't get found below /bin, so this doesn't matter. ) endif() 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
