Hi Steve, FYI, I've been a CMake core developer since 2001.
steve naroff wrote:
From my perspective, not being able to use relative paths just seems 'broken'. The reason for this limitation is totally unclear to someone like me (who is an 'end user' of cmake). I'd love to hear a thoughtful list of reasons why relative paths are so hard for cmake to cope with (from one of the lead developers, if possible).
In principle you are correct...with enough effort the build system that CMake generates could use relative paths to refer to the source tree from the build tree in the common case. It's not easy...there are a lot of places that paths appear. Some of them are mentioned in the user-maintained FAQ: http://www.cmake.org/Wiki/CMake_FAQ#Why_does_CMake_use_full_paths.2C_or_can_I_copy_my_build_tree.3F The answer there could use some refinement, but it is generally correct. We support "out-of-source source" where a source tree from somewhere outside the main source tree on disk is given to add_subdirectory() by a full path. Perhaps if it were given as a relative path then we could honor that too, but that is also more effort. However, the above-mentioned effort is not worthwhile in our opinion because relative/full path issues are not the only reason that CMake does not generate redistributable build files. CMake build trees have a lot of *stateful* per-machine information in the CMakeCache.txt and a few other files, including the following: - Full path to the compiler(s), and compiler vendor identification - Target architecture properties (32-bit v. 64-bit, etc.) - Results from try-compile tests - Results from find_program, find_library, and other search commands Much of this information is needed to support system introspection features, which is one of the features that makes CMake so powerful. Initializing and maintaining it requires CMake to be installed on the build machine. It is possible to relocate build trees if all of the above stateful information remains valid in the new locations. By the time that happens, the new locations are so similar to the old location that you might as well distribute a pre-compiled binary. In return for the above explanation, I request an explanation as to the restrictions that make distributing CMake so hard, particularly on machines that already have the entire GNU toolchain. Have you ever tried to build GCC 4.4 and all its dependencies from scratch? It's do-able, but the effort is much greater than installing CMake. If there is any reason not to install CMake other than "it's another dependency", perhaps we can address it. If the only reason is that "it's another dependency", consider that once CMake is installed it can find all the *other* dependencies automatically on most systems. -Brad _______________________________________________ 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
