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

[Willy Lambert]

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


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)