[CMake] Cmake absolute paths with gcc, __FILE__ , and logging

Willy Lambert lambert.willy at gmail.com
Mon Jan 7 03:40:09 EST 2013


2013/1/4 Andreas Mohr <andi at lisas.de>:
> Hi,
>
> On Fri, Jan 04, 2013 at 11:47:40AM -0500, cmake-request at cmake.org wrote:
>> Date: Fri, 4 Jan 2013 16:58:05 +0100
>> From: Willy Lambert <lambert.willy at gmail.com>
>
>> 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/


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

>
> 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.


More information about the CMake mailing list