>> There are lots of questions on this CMake variable and the consensus is DO >> NOT USE IT. PERIOD. The implementation is basically broken for all but the >> most trivial case. > >I can tell you one thing. If the original idea of this was an attempt >to create a CMake free build that will not work.
These comments agree with the way my software group has used CMake on a daily basis for the past 6 or 7 years (or more?). For our project, with a couple thousand source code files in a few dozen directories, it only takes a minute for CMake to generate our VC++ project files, and we make heavy use of out-of-source builds and different relative paths to source code files, all of which says you'd be crazy to rely on relative paths in the project files. Every once in a while, though, we get some pushback from our parent group, for whom my software project is just one subcomponent of a larger system. For example, today a very influential member of the larger team complained that he can't attach a debugger to our project on one of the test machines because we don't use relative paths in our project files (unlike "everyone else"). Supposedly he can take the source code directory of any other subsystem (including all its VCPROJ files with their relative paths to everything), drop it onto an arbitrary directory on the test machine, open up VC++ and attach the debugger to a running executable of that subsystem. I don't know if relative paths would even work in our case, but it would be very helpful if I could just twiddle some setting in my top-level CMakeLists.txt, produce a version of the project files with all relative paths, and either solve this guy's problem or show him that relative paths aren't the answer after all. NOT having the ability (or at least know-how) to generate projects with relative paths, I leave someone with an unsolved problem that seems to be my fault (because my group keeps on using CMake) and increases the risk that I'll eventually be forced to go back to using individually-crafted VCPROJ files for everything, which IMHO would be a huge step backward in my development process. As a result, even though it's been years since I've even THOUGHT about using relative paths, I'm temporarily setting CMAKE_USE_RELATIVE_PATHS in a copy of my source tree to see what happens. So far, though, it doesn't seem to help much. The paths to libraries that are given by relative paths in CMakeLists.txt seem to stay relative paths rather than being converted to absolute, but all the source files are still identified by absolute paths regardless. David _______________________________________________ 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
