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

[Willy Lambert]

really sorry, last mail was sent too early X-(

2013/1/7 Willy Lambert <lambert.willy at gmail.com>:
> 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/
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.