/usr/share/cmake/Modules/GNUInstallDirs.cmake and http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=126c993d031f6f7be4970a67621da92f580d4e5a hints that CMAKE_INSTALL_LIBDIR should be "lib" or "lib64", but /etc/rpm/macros.cmake ends up setting it to "/usr/lib" . A relative cmake path will automatically be relative to ${CMAKE_INSTALL_PREFIX} and it will thus often not make any difference in the build process. It do however become a problem when the build system needs to know the absolute path and do something like ${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_LIBDIR} and ends up with /usr/usr/lib. Patching the upstream build system just to be able to build on Fedora doesn't seem like the best solution. It seems to me like macros.cmake should use -DCMAKE_INSTALL_LIBDIR:PATH=%{_lib} As a workaround I can use %cmake -DCMAKE_INSTALL_LIBDIR:PATH=%{_lib} . cmake-2.8.7-4.fc16.i686 rpm-4.9.1.2-5.fc16.i686
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.