2013/1/7 Willy Lambert <[email protected]>: > really sorry, last mail was sent too early X-( > > 2013/1/7 Willy Lambert <[email protected]>: >> 2013/1/4 Andreas Mohr <[email protected]>: >>> 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). >> >> Depends what you listen under standard. In my case it's standrd with >> GNU tools. If you know how I could log filename + line number in a >> standardized way let me know (or point links), I'll be very happy for >> that. For now, I'm only expected my project working with GNU, and only >> it (which is rather by necessity than by choice). >> >>> 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), >> >> Yes and no. Yes, CMake has to manage a "source root dir" and a "binary >> output dir" (and maybe a relative path from source to build ?), but >> I'm not sure that you *need* it to build (see the >> CMAKE_USE_RELATIVE_PATHS option that is already working on simple >> cases). In my case, it's a "classical" CMake tructure : >> myproject/ > build > src > > so I understand that cmake has to know about internal src/build > structure (and I wouldn't mind cmake using src/XXX path without being > able to prevent the src particule which is not a problem). What I > don't want is having information in my binaries about my "myproject" > folder location. > >> >> >> So it's a strong reason in current implementation, not sure it is >> justified. Nevertheless I'm aware that as all free project it has >> limitation, lack of contributions, etc, ... what I mean is that I'm >> not sure that the onus of this is *only* my project. >> >> I have 3 solutions (in this order of priority) : >> _ extending Cmake >> _ finding a hack >> _ changing log system (for an obvious reason you can't switch easily >> an existing project regarding log because there are lot of work to do) >> >> >>> 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). >> >> It's not really improper since I choosed GNU gcc, so everything is >> behaving as expected. What is not behaving as expected (on my point of >> view, with is relative), the improper assumption is that Cmake doesn't >> hide > the path to the project > >> >>> >>> 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). > > Thanks for pointing this link, very interesting. > The strrchr() solution is demanding computation at run time, which is > quite a pity (not to see a problem as it is an embedded project). > But at least it's a solution. > > >>> >>> >>>> 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. > > Thanks for this detailed output, it really helps a lot.
Hi all, I'm back with some experimentations. On my project the set(CMAKE_USE_RELATIVE_PATHS ON) seems to work and to answer my needs. The structure of the project is simple (meaning a quite standard out of sources build), but it has quite important contents (several binaires, librairies, custom target to generate sources that I build in the flow,...). However I'm not using any "make install", CPack or other things that could be bite by relative paths. I wonder what is not supposed to work then ? (I'm under linux) -- 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
