Bug 795542
Summary: | CMAKE_INSTALL_LIBDIR is usually a relative path but is absolute path on Fedora | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Mads Kiilerich <mads> |
Component: | cmake | Assignee: | Orion Poplawski <orion> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 16 | CC: | b.brachaczek, jreznik, kevin, orion, pertusus, pmachata, rdieter |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | 2.8.7-6 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-08-03 16:01:41 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Mads Kiilerich
2012-02-20 19:57:41 UTC
That's... unfortunate. *lots* of projects in the wild already assume this is absolute. I guess I'll have to review a sample of our cmake-based packages, and see how bad this could be. (any other ideas?) Rex - This setting was influenced by some relatively early cmake adopters like plplot. I've found at least one other project (tkimg) which seems to use the relative path convention. I've posted to the cmake list for some more discussion. It would be good to know what projects in fedora use what. Agreed, I'll follow-up soon (sometime tomorrow hopefully) with my findings Yeah, I suspect there are some projects assuming this is absolute, though I also had to patch some CMake files of projects which assume it's relative (and some other maintainers use other workarounds, like redefining the setting on the command line, or even calling cmake directly instead of %cmake or %cmake_kde4 (against the guidelines)). It's an unfortunate mess. (I'd say this is a case of CMake being too smart and lenient. If it required either an absolute path (only, banning relative ones) or a relative path (only, banning absolute ones) in every command rather than accepting either, we probably wouldn't have ended up with this confusion. But of course this cannot be changed for obvious compatibility reasons.) My current plan is to strip the %cmake macro options down to: -DCMAKE_VERBOSE_MAKEFILE=ON \\\ -DCMAKE_INSTALL_PREFIX:PATH=%{_prefix} \\\ -DBUILD_SHARED_LIBS:BOOL=ON and build that for rawhide. kde packages seem to use the %cmake_kde4 macro and that does not have CMAKE_INSTALL_LIBDIR defined. Uhm: * Please leave the %{?_cmake_lib_suffix64} in! * We probably need LIB_INSTALL_DIR set one way or the other. Otherwise, many packages will be broken for multilib. (In reply to comment #7) > * Please leave the %{?_cmake_lib_suffix64} in! It's still in %cmake_kde4 which is what seems to use it. Also, those projects should probably migrate the the GNUInstallDirs convention if needed. > * We probably need LIB_INSTALL_DIR set one way or the other. > Otherwise, many packages will be broken for multilib. We'll see. Packagers can always add defines they need for their packages. > It's still in %cmake_kde4 which is what seems to use it. Several non-KDE projects also need LIB_SUFFIX. Some of them are part of e.g. kdesupport, some are just completely non-KDE projects which just happen to also need this feature. > Packagers can always add defines they need for their packages. Sure, but what does removing the setting of LIB_SUFFIX achieve? That define isn't breaking anything (unlike CMAKE_INSTALL_LIBDIR). All it's going to achieve is a bunch of pointless FTBFS issues. Oh, and the *_INSTALL_DIR convention is also used by many projects, not just KDE. (Some use only LIB_SUFFIX, some only *_INSTALL_DIR (especially LIB_INSTALL_DIR), some use both, i.e. they use ${CMAKE_INSTALL_PREFIX}/lib${LIB_SUFFIX} if LIB_INSTALL_DIR is not set.) Reading GNUInstallDirs.cmake convinces me that this bug in invalid. CMAKE_INSTALL_LIBDIR isn't guaranteed to be relative, they just say you can use it in the install() CMake command, which is true for both relative and absolute path. And GNUInstallDirs.cmake defines CMAKE_INSTALL_FULL_LIBDIR variable which is guaranteed to be absolute. So packages using ${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_LIBDIR} just need to be fixed and I see no bug here in Fedora/CMake. FWIW, Gentoo also defines CMAKE_INSTALL_LIBDIR to an absolute path. And Gentoo being a source-based distribution would be especially vulnerable to problems with packages assuming the path to be relative. And they handle it. Yes, it is "spec bug" that it is unspecified whether CMAKE_INSTALL_LIBDIR is absolute or relative. It might also be a bug in apps if they assume one of them. But if CMAKE_INSTALL_LIBDIR can be either absolute or relative then I don't see why it would be a problem to make it relative. When CMAKE_INSTALL_FULL_LIBDIR is absolute then it would make a lot of sense if CMAKE_INSTALL_LIBDIR was relative. Pushing in the direction of standardizing on CMAKE_INSTALL_LIBDIR being relative seems like the best way forward. What fix would you recommend for packages using ${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_LIBDIR}? (In reply to comment #12) > What fix would you recommend for packages using > ${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_LIBDIR}? Using ${CMAKE_INSTALL_FULL_LIBDIR}. If GNUInstallDirs is included, it resolves to either ${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_LIBDIR} is CMAKE_INSTALL_LIBDIR relative, and to ${CMAKE_INSTALL_LIBDIR} otherwise. And if someone really needs a relative path, the only portable way I know to achieve it until all parties are convinced that CMAKE_INSTALL_LIBDIR should be always relative, is: file (RELATIVE_PATH CMAKE_INSTALL_RELATIVE_LIBDIR "${CMAKE_INSTALL_PREFIX}" "${CMAKE_INSTALL_FULL_LIBDIR}") ...which puts the relative path into CMAKE_INSTALL_RELATIVE_LIBDIR variable. As of 2.8.7-6, CMAKE_INSTALL_LIBDIR is no longer set in the %cmake macro. Use whatever your project needs. |