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

[Andreas Mohr]

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