Hi, On Fri, Jan 04, 2013 at 11:47:40AM -0500, [email protected] wrote: > Date: Fri, 4 Jan 2013 16:58:05 +0100 > From: Willy Lambert <[email protected]>
> Hi all, > > Short Story : > > I am trying to convert an existing project from Manual Makefiles to > Cmake for building it. > We have a logger that rely on the __FILE__ define to say which file is > "writing" into the log but this is broken by the CMake default > behavior using absolute paths. > So I wonder if there is any way to have the file name in the code to > be able to log "Error : line XXX in file.cpp". > > > > > Long Story : > > > > So I have for instance a source /home/me/src/main.cpp, compiled with > relative paths "gcc -o main.cpp". > So the logger say "Error : line XXX in main.cpp". I'm afraid given the discussion at "Short form of __FILE__" http://bytes.com/topic/c/answers/453661-short-form-__file__ the onus is on your project since it seems to be relying on seemingly rather volatile (non-standardized) behaviour of the __FILE__ macro (compilers seem to be free to pass on either a file's basename only or a relative path or even a FQPN). And now that one is using a CMake build which needs to do builds from an entirely separate binary tree referencing source files in a foreign source tree (thus having a justified reason for needing to specify paths in full), these improper assumptions in your project seem to fall flat on their face, since gcc chooses to prefer to pass on as much information to the __FILE__ macro as it can get about the file location (i.e., full path). Since the problem is thus firmly located on the source code side (i.e. its assumptions about __FILE__), I'd suggest treating the problem right there, using e.g. the discussion's strrchr() solution ("workaround"?) to achieve a slightly improved guarantee of gaining sufficiently constant output format (but note that Keith Thompson noted that the C language itself does not have any business dealing with path separator definitions). > I tried to use the suggested trigger "set_source_files_properties" to > define my own __FILE__ but it doesn't works with included files (it > shows main.cpp instead oh dummy.hpp) > http://www.cmake.org/pipermail/cmake/2011-December/048281.html > > So this way is a dead end because the compilator (and the one that > creates its command line) is the only one to be aware of this > information. > > Beside that, as I would really like to simplify the "VERBOSE=2 make" > output to be able to debug what CMake generates I currently have > plenty of path with 20 or more folder level including many "../..", I > am looking on making CMake giving relatives paths to gcc. I guess the problem is that CMake is operating from a separate binary tree as its base, thus it obviously needs to pass full paths to the source files to the compiler, to get to the "other" source dir "over there". The alternative would be to have cwd set to the source tree directory when launching gcc, to be able to specify source file arguments as file-only (the -o object file argument however should be able to support full paths without any negative effects, right?). > I have seen some thread about the use of CMAKE_USE_RELATIVE_PATHS, but > it seems that it is not working, and maybe with no will to support > this (is that true ?) > http://cmake.3232098.n2.nabble.com/CMAKE-USE-RELATIVE-PATHS-td4042914.html I'm actually rather interested in CMAKE_USE_RELATIVE_PATHS myself, since I'd like to be able to generate a (semi-static) subset of Visual Studio projects for permanently adding them to an existing static .sln (this use case would probably be termed "CMake abuse" by Kitware :). Using CMake for this purpose rather than having to create a couple dozen custom targets manually (which directly translates into creating a couple dozen project files manually) -- and the painful challenge of *updating* them manually and consistently! -- seems like a nice and thus rather justified alternative. Since there's already a (verified working!) possibility (CACHE var <target>_GUID_CMAKE) to have CMake (re-)use a *static* (known) project GUID rather than recreating a random one, inclusion in existing .sln:s (with a requirement of project GUIDs unchanged) would not be a problem there at least. I was rather bewildered as well about the impression that CMAKE_USE_RELATIVE_PATHS is expected to remain (semi-)broken. For people who knowingly want to attempt producing semi-static (SCM-committed) project files rather than fully machine-introspected specifically-pathed *temporary* project files, CMAKE_USE_RELATIVE_PATHS (and possibly avoidance of manual reference to ${CMAKE_PROGRAM} expressions, to try to even avoid any CMake dependency at all) would be very useful. > Does anyone have succeeded with relatives path in CMake ? On my recent VS10 experiments, IIRC I ended up with several absolute paths in project files despite having activated CMAKE_USE_RELATIVE_PATHS. I'm rather tempted to start improving on this situation once some of my other CMake work items are handled. Andreas Mohr -- GNU/Linux. It's not the software that's free, it's you. -- 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
