CMAKE_USE_RELATIVE_PATHS

[barcaroller]

This is a follow up to the message ("Setting variables in CMakeLists.txt")
that I posted on April 30th, 2009.

I am now using cmake 2.8.0 and the CMAKE_USE_RELATIVE_PATHS variable still
does not work.  It does work for in-source builds (when I build the object
files inside the 'src' directory) but it does not work for out-of-source
builds.

The cmake documentation does specify that CMAKE_USE_RELATIVE_PATHS may not
work in complex projects but my project could not be simpler (see below).

  project
     |
     +--- src     <- contains CMakeLists.txt
     |
     +--- build   <- cmake ../src ; make


All directories reside on a local disk.  When I build from the build
directory, the gcc compiler uses absolute pathnames no matter what value the
CMAKE_USE_RELATIVE_PATHS  variable is set at.  This means that the __FILE__
macro uses absolute pathnames, which totally screws up the log files.

Will this ever be fixed or should I give up on out-of-source builds?



_______________________________________________
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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[Bill Hoffman]

barcaroller wrote:

> This is a follow up to the message ("Setting variables in CMakeLists.txt")
> that I posted on April 30th, 2009.
>
> I am now using cmake 2.8.0 and the CMAKE_USE_RELATIVE_PATHS variable still
> does not work.  It does work for in-source builds (when I build the object
> files inside the 'src' directory) but it does not work for out-of-source
> builds.
>
> The cmake documentation does specify that CMAKE_USE_RELATIVE_PATHS may not
> work in complex projects but my project could not be simpler (see below).
>
>   project
>      |
>      +--- src     <- contains CMakeLists.txt
>      |
>      +--- build   <- cmake ../src ; make
>
>
> All directories reside on a local disk.  When I build from the build
> directory, the gcc compiler uses absolute pathnames no matter what value the
> CMAKE_USE_RELATIVE_PATHS  variable is set at.  This means that the __FILE__
> macro uses absolute pathnames, which totally screws up the log files.
>
> Will this ever be fixed or should I give up on out-of-source builds?
>
>

You should give up on CMAKE_USE_RELATIVE_PATHS , and we should deprecate
it from CMake.  It just does not work, and frustrates people.

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[barcaroller]

"Bill Hoffman" wrote:

> You should give up on CMAKE_USE_RELATIVE_PATHS , and we should deprecate
> it from CMake.  It just does not work, and frustrates people.


Fair enough, but what are the alternatives?  My two requirements are:

 - Using out-of-source builds
 - Have the gcc compiler use relative pathnames like

   gcc ../src/foo.c

   and not monstrosities like

   gcc /mount/server/homes/users/devel/proj/system/subsystem/src/foo.c






_______________________________________________
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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[Eric Noulard]

2009/11/21 barcaroller <[hidden email]>:

> Fair enough, but what are the alternatives?  My two requirements are:
>
>  - Using out-of-source builds
>  - Have the gcc compiler use relative pathnames like
>
>   gcc ../src/foo.c
>
>   and not monstrosities like
>
>   gcc /mount/server/homes/users/devel/proj/system/subsystem/src/foo.c

What is the final reason that makes you want to avoid the "monstrosities" ?



--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
_______________________________________________
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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[Bill Hoffman]

barcaroller wrote:

> "Bill Hoffman" wrote:
>
>> You should give up on CMAKE_USE_RELATIVE_PATHS , and we should deprecate
>> it from CMake.  It just does not work, and frustrates people.
>
>
> Fair enough, but what are the alternatives?  My two requirements are:
>
>  - Using out-of-source builds
>  - Have the gcc compiler use relative pathnames like
>
>    gcc ../src/foo.c
>
>    and not monstrosities like
>
>    gcc /mount/server/homes/users/devel/proj/system/subsystem/src/foo.c
>
>

There is no way to do that from CMake.  I consider it a feature since
you can move an executable anywhere on the machine and the debugger
still works.  Is this causing something not to work?

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[barcaroller]

"Eric Noulard" wrote:

> What is the final reason that makes you want to avoid the "monstrosities"?

I do not want the __FILE__ macro to reveal the structure of the project.
Also, I'm trying to keep the log file entries short.

I guess I can wrap __FILE__ with another macro that extracts relative
pathnames, but I was hoping to just use cmake's CMAKE_USE_RELATIVE_PATHS
since it is available.







_______________________________________________
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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[barcaroller]

"Bill Hoffman" wrote:

> There is no way to do that from CMake.  I consider it a feature since you
> can move an executable anywhere on the machine and the debugger still
> works.  Is this causing something not to work?

Kindly see my response to Eric.  In regards to the debugger; this is
precisely why I prefer relative pathnames.  I can move my project (with its
source code) to another target machine (using a different top directory),
and still have gdb working properly.




_______________________________________________
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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[Bill Hoffman]

barcaroller wrote:

> "Eric Noulard" wrote:
>
>> What is the final reason that makes you want to avoid the "monstrosities"?
>
> I do not want the __FILE__ macro to reveal the structure of the project.
> Also, I'm trying to keep the log file entries short.
>
> I guess I can wrap __FILE__ with another macro that extracts relative
> pathnames, but I was hoping to just use cmake's CMAKE_USE_RELATIVE_PATHS
> since it is available.
>

I see, sorry....   It is really hard to make everything work with
relative paths, and you don't get that much out of it, except lots of
maintenance issues and corner cases that do not work...  Sounds like
doing it from the C/C++ code would be the best way for you to go.


-Bill

_______________________________________________
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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[Eric Noulard]

2009/11/21 barcaroller <[hidden email]>:

>
> "Eric Noulard" wrote:
>
>> What is the final reason that makes you want to avoid the "monstrosities"?
>
> I do not want the __FILE__ macro to reveal the structure of the project.
> Also, I'm trying to keep the log file entries short.
>
> I guess I can wrap __FILE__ with another macro that extracts relative
> pathnames, but I was hoping to just use cmake's CMAKE_USE_RELATIVE_PATHS
> since it is available.

I had the very same issue and decided to wrap with
basename function which is unfortunately evaluated at runtime.

with GCC you have gcc specific macro: __BASE_FILE__

another way to amortize the runtime cost is to initialize a static variable
for each file, something like:

static const char* static_filename = basename(__FILE__);

then you use "static_filename" in your source file.

--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
_______________________________________________
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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake