On 05/03/2011 11:17 AM, Pere Mato Vila wrote: > >> CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR) >> PROJECT(PREFIX C) >> SET(CMAKE_VERBOSE_MAKEFILE ON) >> ADD_LIBRARY(f SHARED f.c) >> INSTALL(TARGETS f >> RUNTIME DESTINATION bin >> LIBRARY DESTINATION lib >> ARCHIVE DESTINATION lib) >> >> with ${CMAKE_SOURCE_DIR}/f.c containing just "void f(void){}". After >> configuring/building/installing, a reconfiguration with a modified >> CMAKE_INSTALL_PREFIX does not result in recompiling or relinking. > > > Hi Michael, > > In you simple example adding SET(CMAKE_INSTALL_RPATH > "${CMAKE_INSTALL_PREFIX}/lib") before ADD_LIBRARY(...) does trigger a > re-build of the library when changing the length of CMAKE_INSTALL_PREFIX. The > reason for this behavior was given by Alex Neundorf: > >> Then you set the install RPATH once to "/build/mato/ROOT/install/lib" and >> then >> to "/build/mato/ROOT/install2/lib", which is one byte longer. So the binary >> has to be created again with one byte more room for the install RPATH.
Yes, that's true, indeed, but one must distinguish two factors: 1. Basically, it's the incorporation of the CMAKE_INSTALL_PREFIX in the library via CMAKE_INSTALL_RPATH that causes the library to be relinked when CMAKE_INSTALL_PREFIX changes. This is why I have said that solely changing the latter doesn't cause any recompilation or relinking; one rather needs further interconnections for this to happen. 2. The, say, placeholder mechanism described by Alex is the reason why the library is relinked in the *build tree* when CMAKE_INSTALL_RPATH's length changes although the latter isn't incorporated in the library's build-tree-instance due to CMAKE_BUILD_WITH_INSTALL_RPATH being FALSE. If I understand correctly, it's this second point which causes your astonishment, but it already happens during the build phase in the build tree, not just when installing with "make install", right? > The fact that the build is re-done because I change the length of the > installation destination I would call this a bug and not really a feature. IMO, it's not a bug, but even quite clever. The placeholder mechanism allows to avoid a complete relink operation at installation time when the final RPATH must be written to the installed binaries. Look at the cmake_install.cmake script for the above-noted project with the line SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib") you mentioned. You will find a FILE(INSTALL ...) followed by a FILE(RPATH_CHANGE ...) which operates on the already installed library. The latter command is implemented by cmSystemTools::ChangeRPath() and probably much cheaper than a full-featured invocation of the linker involving fork()/exec(), the compiler's front-end, object files, libraries, LTO, recompilation of automatically generated source code etc. In other words: Linking might be expensive, but patching binaries is not. Now, with the placeholder mechanism, you currently have two (re)link operations: One for each CMAKE_INSTALL_PREFIX in the build tree, but none during the two installations. Without the placeholder mechanism, you'd need three operations: One in the build tree without the final RPATHs or placeholders and one during each of the two installations. Therefore, the placeholder mechanism is highly useful - despite the potentially surprising relink operations within the build tree. Regards, Michael _______________________________________________ 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://www.cmake.org/mailman/listinfo/cmake