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

[Willy Lambert]

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

Going further, if I have a file "dummy.hpp" included from main.cpp
that have for any reason an inlined function that log something, it
will say "Error : line YYYin dummy.hpp" from main.cpp. This is due to
the fact that gcc plays with __FILE__ behind the scene.

What defines the __FILE__ value is the path given to the preprocessor
(so the one given to gcc, so the one given by the makefile generated
by CMake). So now I have something like :
"Error : line XXX in /home/me/src/main.cpp"
which is very anoying because :
1/ it reduces lisibility
2/ it show a wrong path when the project is on another machine.


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

Does anyone have succeeded with relatives path in CMake ?

[Willy Lambert]

Post by Willy Lambert
Hi all,
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".
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".
Going further, if I have a file "dummy.hpp" included from main.cpp
that have for any reason an inlined function that log something, it
will say "Error : line YYYin dummy.hpp" from main.cpp. This is due to
the fact that gcc plays with __FILE__ behind the scene.
What defines the __FILE__ value is the path given to the preprocessor
(so the one given to gcc, so the one given by the makefile generated
"Error : line XXX in /home/me/src/main.cpp"
1/ it reduces lisibility
2/ it show a wrong path when the project is on another machine.
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 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

for completeness :
http://public.kitware.com/Bug/view.php?id=12563

I'm under linux, is this just a problem under MSVC ?

Post by Willy Lambert
Does anyone have succeeded with relatives path in CMake ?

[Andreas Mohr]

Hi,

Date: Fri, 4 Jan 2013 16:58:05 +0100
Hi all,
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".
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

[Willy Lambert]

Post by Andreas Mohr
Hi,

Date: Fri, 4 Jan 2013 16:58:05 +0100
Hi all,
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".
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).

Post by Andreas Mohr
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)

Post by Andreas Mohr
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

Post by Andreas Mohr
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.

[Willy Lambert]

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

Post by Willy Lambert

Post by Andreas Mohr
Hi,

Date: Fri, 4 Jan 2013 16:58:05 +0100
Hi all,
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".
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).

Post by Andreas Mohr
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
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.

Post by Willy Lambert
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.
_ 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)

Post by Andreas Mohr
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

Post by Willy Lambert

Post by Andreas Mohr
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.

Post by Willy Lambert

Post by Andreas Mohr

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.

[Willy Lambert]

Post by Willy Lambert
really sorry, last mail was sent too early X-(

Post by Willy Lambert

Post by Andreas Mohr
Hi,

Date: Fri, 4 Jan 2013 16:58:05 +0100
Hi all,
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".
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).

Post by Andreas Mohr
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
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.

Post by Willy Lambert
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.
_ 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)

Post by Andreas Mohr
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

Post by Willy Lambert

Post by Andreas Mohr
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.

Post by Willy Lambert

Post by Andreas Mohr

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)

[Gregor Jasny]

Hello Willy,

Post by Willy Lambert
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".

This is somewhat hackish and should be surrounded by a check for the
Makefile generator:

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -D__FILENAME__='\"$(subst
${CMAKE_SOURCE_DIR}/,,$(abspath $<))\"'")

Thanks,
Gregor

[Willy Lambert]

Post by Gregor Jasny
Hello Willy,

Post by Willy Lambert
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".

This is somewhat hackish and should be surrounded by a check for the
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -D__FILENAME__='\"$(subst
${CMAKE_SOURCE_DIR}/,,$(abspath $<))\"'")
Thanks,
Gregor

Thanks ! This is working and is a great solution for us. CMake is in
love with abspath anyway, so whatever I'll do, it'll be hackish.

I wasn't aware that CMake was letting us hacking with make likewise. I
agree it is not a clean way but when it is the only solution it is a
good exit gate when converting project from makefiles. Is this
features expected by CMake or is it a un-wanted bug ? May I rely on
Cmake kepping this behavior in futur versions.

Post by Gregor Jasny
--
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
http://www.cmake.org/mailman/listinfo/cmake

[Willy Lambert]

Post by Willy Lambert

Post by Gregor Jasny
Hello Willy,

Post by Willy Lambert
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".

This is somewhat hackish and should be surrounded by a check for the
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -D__FILENAME__='\"$(subst
${CMAKE_SOURCE_DIR}/,,$(abspath $<))\"'")
Thanks,
Gregor

Thanks ! This is working and is a great solution for us. CMake is in
love with abspath anyway, so whatever I'll do, it'll be hackish.
I wasn't aware that CMake was letting us hacking with make likewise. I
agree it is not a clean way but when it is the only solution it is a
good exit gate when converting project from makefiles. Is this
features expected by CMake or is it a un-wanted bug ? May I rely on
Cmake kepping this behavior in futur versions.

ehhhhh, in fact it works only for the cpp file. But included files are
not stated correctly (case of inlined functions)...
But it's a step.

Post by Willy Lambert

Post by Gregor Jasny
--
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
http://www.cmake.org/mailman/listinfo/cmake