Created attachment 557780 [details, diff] cmake-utils.eclass.patch Bug #649200 overcome some problems on Gentoo/FreeBSD systems but creates other issues with not Gentoo/FreeBSD systems as well. In fact, build systems that use variables generated by GNUInstallDirs expect them to be relative paths! The whole GNUInstallDirs macro part is the following: if(CMAKE_SYSTEM_NAME MATCHES "^(.*BSD|DragonFly)$") _GNUInstallDirs_cache_path_fallback(CMAKE_INSTALL_INFODIR "info" "Info documentation (info)") _GNUInstallDirs_cache_path_fallback(CMAKE_INSTALL_MANDIR "man" "Man documentation (man)") else() _GNUInstallDirs_cache_path_fallback(CMAKE_INSTALL_INFODIR "${CMAKE_INSTALL_DATAROOTDIR}/info" "Info documentation (DATAROOTDIR/info)") _GNUInstallDirs_cache_path_fallback(CMAKE_INSTALL_MANDIR "${CMAKE_INSTALL_DATAROOTDIR}/man" "Man documentation (DATAROOTDIR/man)") endif() So the patch applied to the cmake-utils.eclass in incomplete, I am suggesting the attached patch to complete the fix. It fixes also a problem with CMAKE_INSTALL_DOCDIR which should be a relative path as well. For the CMAKE_INSTALL_DOCDIR part, the fix for EAPI7 was introduced by commit https://gitweb.gentoo.org/repo/gentoo.git/commit/eclass/cmake-utils.eclass?id=da2f96d0b25ce88035f1442c965ac64c95994bd8. Again the variable is set as an absolute path, for the same reason cited above I think it should be relative. I have also found the explanation (for the absolute solution) here: https://linux.gentoo.dev.narkive.com/djcIJzLs/gentoo-dev-patch-cmake-utils-eclass-override-cmake-install-docdir-in-eapi-7. Here are my comments regarding the original motivations by mgorny: a. that's what PMS does for econf, -> It breaks all the cmakelist files that follow the rules and then expect relative paths ad documented by GNUInstallDirs (i.e. in that case all the ebuilds should fix the eclass behavior). b. and more importantly, it means that when people need to override install prefix (e.g. install to / or /opt/foo), we will still use the correct docdir as defined by Gentoo policy -> Probably it's better to put a note in the documentation when overriding install prefix or the QA checks should identify the issue. When someone changes the standard behavior than it must verify that everything else satisfies Gentoo policy (like the docdir Gentoo policy).
(In reply to Fabio Rossi from comment #0) > Bug #649200 overcome some problems on Gentoo/FreeBSD systems but creates > other issues with not Gentoo/FreeBSD systems as well. In fact, build systems > that use variables generated by GNUInstallDirs expect them to be relative > paths! That's only if you make that implicit assumption. Lots of upstream build systems using GNUInstallDirs try to build their own paths using CMAKE_INSTALL_PREFIX and some dodgy string manipulation hackery. The correct solution is to use CMAKE_INSTALL_FULL_* variables that include the correct prefix (for instance, for inserting into .pc files). > > The whole GNUInstallDirs macro part is the following: > > if(CMAKE_SYSTEM_NAME MATCHES "^(.*BSD|DragonFly)$") > _GNUInstallDirs_cache_path_fallback(CMAKE_INSTALL_INFODIR "info" > "Info documentation (info)") > _GNUInstallDirs_cache_path_fallback(CMAKE_INSTALL_MANDIR "man" > "Man documentation (man)") > else() > _GNUInstallDirs_cache_path_fallback(CMAKE_INSTALL_INFODIR > "${CMAKE_INSTALL_DATAROOTDIR}/info" > "Info documentation (DATAROOTDIR/info)") > _GNUInstallDirs_cache_path_fallback(CMAKE_INSTALL_MANDIR > "${CMAKE_INSTALL_DATAROOTDIR}/man" > "Man documentation (DATAROOTDIR/man)") > endif() > > So the patch applied to the cmake-utils.eclass in incomplete, I am > suggesting the attached patch to complete the fix. It fixes also a problem > with CMAKE_INSTALL_DOCDIR which should be a relative path as well. > > For the CMAKE_INSTALL_DOCDIR part, the fix for EAPI7 was introduced by > commit > https://gitweb.gentoo.org/repo/gentoo.git/commit/eclass/cmake-utils. > eclass?id=da2f96d0b25ce88035f1442c965ac64c95994bd8. Again the variable is > set as an absolute path, for the same reason cited above I think it should > be relative. I have also found the explanation (for the absolute solution) > here: > https://linux.gentoo.dev.narkive.com/djcIJzLs/gentoo-dev-patch-cmake-utils- > eclass-override-cmake-install-docdir-in-eapi-7. Here are my comments > regarding the original motivations by mgorny: > > a. that's what PMS does for econf, > > -> It breaks all the cmakelist files that follow the rules and then expect > relative paths ad documented by GNUInstallDirs (i.e. in that case all the > ebuilds should fix the eclass behavior). Can you show a valid bug of this breaking?
My recent test with https://gitweb.gentoo.org/repo/gentoo.git/commit/sci-biology/bamtools?id=e47f0847b07adb2e6d9bb0f3b1bd491c6f3535fa Injected all the correct paths into the .pc files and installed the documentation into the correct directory. So you'll have to show me an example of real breakage before I consider the case for relative paths valid.
The cmake documentation says that CMAKE_INSTALL_FULL_* is always promoted to an absolute path. My assumption derived from the GNUInstallDirs documentation which indicates default CMAKE_INSTALL_* variables with relative paths. But I agree with you, after having looked at the GNUInstallDirs_get_absolute_install_dir() macro, CMAKE_INSTALL_* can be absolute forcing the value of CMAKE_INSTALL_FULL_*. I am closing this bug, sorry for the noise.
