| Summary: | %cmake RPM macro is not compatible with GNUInstallDirs.cmake | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Roman Tsisyk <roman> |
| Component: | cmake | Assignee: | Orion Poplawski <orion> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | denis, helio, jreznik, ltinkl, orion, rdieter |
| Target Milestone: | --- | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-08-18 01:33:25 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Roman Tsisyk
2016-01-25 19:48:40 UTC
May make sense to come up with a new macro that uses these new GNUInstallDirs-style variables/paths, affording the ability to drop legacy cruft used in %%cmake , something like: %cmake_gnu or %cmake_gnuinstalldirs (latter certainly is long, but more descriptive) We definitely need a new macro - there is a conflict between the common cmake usage of CMAKE_INSTALL_LIBDIR as something that is appended to CMAKE_INSTALL_PREFIX, and GNUInstallDirs' usage as a full path. We used to define CMAKE_INSTALL_LIBDIR in %cmake but had to remove it because of this. I've not yet run into a package that needed to define all of these, but I concur that a %cmake_gnuinstalldirs macro could be useful. After looking at this closer, it actually appears that the expected usage of the CMAKE_INSTALL_<dir> paths by GNUInstallDirs are the relative paths, although you can set them to absolute paths. See https://cmake.org/cmake/help/v3.4/module/GNUInstallDirs.html And with just: cmake_minimum_required(VERSION 2.8) include(GNUInstallDirs) and cmake -DCMAKE_INSTALL_PREFIX=/usr .. I end up with: CMAKE_INSTALL_FULL_BINDIR = /usr/bin CMAKE_INSTALL_FULL_DATADIR = /usr/share CMAKE_INSTALL_FULL_DATAROOTDIR = /usr/share CMAKE_INSTALL_FULL_DOCDIR = /usr/share/doc/Project CMAKE_INSTALL_FULL_INCLUDEDIR = /usr/include CMAKE_INSTALL_FULL_INFODIR = /usr/share/info CMAKE_INSTALL_FULL_LIBDIR = /usr/lib64 CMAKE_INSTALL_FULL_LIBEXECDIR = /usr/libexec CMAKE_INSTALL_FULL_LOCALEDIR = /usr/share/locale CMAKE_INSTALL_FULL_LOCALSTATEDIR = /var CMAKE_INSTALL_FULL_MANDIR = /usr/share/man CMAKE_INSTALL_FULL_OLDINCLUDEDIR = /usr/include CMAKE_INSTALL_FULL_SBINDIR = /usr/sbin CMAKE_INSTALL_FULL_SHAREDSTATEDIR = /usr/com CMAKE_INSTALL_FULL_SYSCONFDIR = /etc The only ones that are incorrect are DOCDIR and SHAREDSTATEDIR, so I would be tempted to just add these two to the current %cmake macro. Possible, but doing it that way means the new macro won't respect other well-known rpm macros like:
%{_bindir}, %{_libdir}, %{_datadir}, %{_localstatedir}, %{_mandir} etc...
Orion, I'm sorry. It seems that this bug has already been fixed in rawhide.
Here is my output from CentOS 6, CentOS 7, Fedora 22, Fedora 23 (official Docker images):
```
-- CMAKE_INSTALL_FULL_SYSCONFDIR /usr/etc <!-- Invalid value
-- CMAKE_INSTALL_FULL_BINDIR /usr/bin
-- CMAKE_INSTALL_FULL_SBINDIR /usr/sbin
-- CMAKE_INSTALL_FULL_LIBDIR /usr/lib64
-- CMAKE_INSTALL_FULL_LIBEXECDIR /usr/libexec
-- CMAKE_INSTALL_FULL_LOCALSTATEDIR /usr/var
-- CMAKE_INSTALL_FULL_SHAREDSTATEDIR /usr/com
-- CMAKE_INSTALL_FULL_DATADIR /usr/share
-- CMAKE_INSTALL_FULL_INCLUDEDIR /usr/include
-- CMAKE_INSTALL_FULL_INFODIR /usr/share/info
```
Compare with rawhide:
```
-- CMAKE_INSTALL_FULL_SYSCONFDIR /etc <!-- correct
-- CMAKE_INSTALL_FULL_BINDIR /usr/bin
-- CMAKE_INSTALL_FULL_SBINDIR /usr/sbin
-- CMAKE_INSTALL_FULL_LIBDIR /usr/lib64
-- CMAKE_INSTALL_FULL_LIBEXECDIR /usr/libexec
-- CMAKE_INSTALL_FULL_LOCALSTATEDIR /var
-- CMAKE_INSTALL_FULL_SHAREDSTATEDIR /usr/com
-- CMAKE_INSTALL_FULL_DATADIR /usr/share
-- CMAKE_INSTALL_FULL_INCLUDEDIR /usr/include
-- CMAKE_INSTALL_FULL_INFODIR /usr/share/info
-- CMAKE_INSTALL_FULL_MANDIR /usr/share/man
```
This ticket probably should be closed if nobody wants a proper default value of SYSCONFDIR in Fedora 22, Fedora 23, EPEL 6, EPEL 7, etc. I'll kept only `-DCMAKE_INSTALL_SYSCONFDIR:PATH=%{_sysconfdir}` for compatibility in my specs.
Ahh, CMAKE_INSTALL_FULL_LOCALSTATEDIR /usr/var is also incorrect. I see that this problem was fixed in upstream CMake: https://github.com/Kitware/CMake/blob/master/Modules/GNUInstallDirs.cmake#L323-L353 (In reply to Roman Tsisyk from comment #5) > Orion, I'm sorry. It seems that this bug has already been fixed in rawhide. ... > This ticket probably should be closed if nobody wants a proper default value > of SYSCONFDIR in Fedora 22, Fedora 23, EPEL 6, EPEL 7, etc. According the list above, CMAKE_INSTALL_FULL_SHAREDSTATEDIR (and maybe also CMAKE_INSTALL_FULL_DOCDIR) is still invalid in Rawhide. I believe after the fix it should be ported to epel{6,7} to generalize macros set and avoid all possible discrepancies in EPEL in the future. > Ahh, CMAKE_INSTALL_FULL_LOCALSTATEDIR /usr/var is also incorrect. But according your list above it's sane: -- CMAKE_INSTALL_FULL_LOCALSTATEDIR /var > But according your list above it's sane:
> -- CMAKE_INSTALL_FULL_LOCALSTATEDIR /var
It is sane only on rawhide. Other releases uses /usr/var.
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase Are there any changes here since cmake 3.4.3 / 3.5.0rc landed to rawhide? As for the fixed macros backporting, I do believe that it would be worth to el6, epel7 and f23 (at least). marking FutureFeature, to avoid auto-close I believe this ticket can be closed as no more actual, in terms of recent Fedora and EPEL8. OK, thanks. |