(0032202)
Mika Fischer (reporter)
2013-02-05 16:53

Same issue applies to include directories.

Fixed in patch v2.

(0032241)
Peter Kuemmel (developer)
2013-02-09 06:09

The initial ninja generator implementation has used many (only?) relative paths (not only for source files). As I could remember this was the root of several bugs which are fixed now.

I fear that changing the default for paths opens a can of worms.

Best would be do a complete review of paths used in the ninja generator, and have a look at the patches of already fixed bugs.

(0032242)
Mika Fischer (reporter)
2013-02-09 06:42

Do you have an example? I just went through the closed Ninja bugs here and could not find anything.

I would have thought that absolute paths make things simpler and more robust...

Further, I'm not changing any default. Just the way source files and include directories are passed to the compiler. Everything else should not be affected by this.

(0032311)
Peter Kuemmel (developer)
2013-02-16 08:17

Thanks, commited you patch: http://public.kitware.com/pipermail/cmake-commits/2013-February/014499.html [^]

(0032315)
Peter Kuemmel (developer)
2013-02-16 10:31

I've reverted the patch.
As I feared, after touching the paths dependency tracking is broken and I also see a lot of empty calls.

(0032317)
Mika Fischer (reporter)
2013-02-16 10:49

I see. Unfortunately I don't have the time to delve deep enough into the Cmake code to try to properly fix this and I'm sure there are more important issues for you to work on as well.

But maybe we could leave this bug here to give someone else who wants to make cmake + ninja + vim work better together a starting point?

(0035339)
Ben Boeckel (developer)
2014-03-07 11:49

I can't reproduce this anymore. I don't know whether Ninja or Vim got smarter, but sitting in the source tree with an external build tree gets me to the right place and the same after doing ":cd src" and another build. FWIW, I'm also using "ninja -C $dir", so maybe ninja knows to DTRT in this case; are you doing the equivalent of "cd $dir && ninja"?

(0035340)
Ben Boeckel (developer)
2014-03-07 11:52

Actually, it seems Vim and Ninja got smart. The actual output is:

/home/boeckb/code/$proj/src/src/path/to/file.h:40:2: error: #error foo

and the QuickFix window shows and gets to the right place:

src/path/to/file.h:40:2: error: #error foo

After the ":cd", Vim strips off another leading path component.

vim-enhanced-7.4.179-1.fc20.x86_64
ninja is 1.4.0.git

(0036547)
Colin D Bennett (reporter)
2014-08-04 16:49

This is an issue for me in an IDE as well (Eclipse and Freescale CodeWarrior). Because the compiler is given relative paths to the source files, the error and warning messages also contain these relative paths. But because I'm using an out-of-source build, where the build directory may be "../_build" relative to the source directory (i.e. the output directory is a sibling of the source directory), the relative paths to source files are given relative to this out-of-source build directory. So they look like "../myproject/blah.c" and the IDE is confused.

I implemented a crude workaround by writing a Python script which sits as a "proxy" interposed as the compiler in CMake. My toolchain file forces the CMAKE_C_COMPILER and CXX compiler to call PYTHON_EXECUTABLE and pass my filter script as the first argument. This Python script acts as a filter, resolving any relative file paths in warning/error messages into absolute file paths.

How hard would it be to expand all file paths to absolute paths before calling external tools? Or resolve to absolute paths early and then CMake could always handle files as absolute paths internally? You could always make a file path relative to the source directory again, so it's essentially a reversible process (except if the relative path is "non-normalized" in that there are redundant ../foo/.. elements etc.).

(0038992)
Scott Kevill (reporter)
2015-06-26 12:56

This is more serious than just inconsistent error messages.

It causes gcc to store relative paths for the debug info directory paths inside executables, which means gdb can no longer find the original source files. It's especially bad for building RPMs where rpmbuild is automatically extracting the debuginfo and original source files into separate RPMs to store at a different install location (ie. /usr/src/debug/package/....). This completely breaks when relative paths are generated.

How does this break dependency tracking if absolute paths are only being passed to the compiler?

(0039523)
James Johnston (developer)
2015-10-06 15:31

This is an issue in another IDE as well: Atmel Studio. Although CMake doesn't support Atmel Studio project generation, I wrote some custom CMake code for generating these projects and putting them in the build tree for an out-of-source build.

Everything works great, except warnings and errors with relative paths are being incorrectly resolved to absolute paths by the IDE.

(0042218)
Kitware Robot (administrator)
2016-06-10 14:28

Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

Issue History
Date Modified	Username	Field	Change
2013-02-05 16:37	Mika Fischer	New Issue
2013-02-05 16:37	Mika Fischer	File Added: cmake-ninja-absolute-filenames.patch
2013-02-05 16:53	Mika Fischer	Note Added: 0032202
2013-02-05 16:53	Mika Fischer	File Added: cmake-ninja-absolute-filenames-v2.patch
2013-02-06 09:22	Brad King	Assigned To	=> Peter Kuemmel
2013-02-06 09:22	Brad King	Status	new => assigned
2013-02-09 06:09	Peter Kuemmel	Note Added: 0032241
2013-02-09 06:42	Mika Fischer	Note Added: 0032242
2013-02-09 07:03	Peter Kuemmel	Summary	Ninja generator uses relative paths for source files => Ninja: generator uses relative paths for source files
2013-02-16 08:17	Peter Kuemmel	Note Added: 0032311
2013-02-16 08:17	Peter Kuemmel	Status	assigned => resolved
2013-02-16 08:17	Peter Kuemmel	Fixed in Version	=> CMake 2.8.11
2013-02-16 08:17	Peter Kuemmel	Resolution	open => fixed
2013-02-16 10:31	Peter Kuemmel	Note Added: 0032315
2013-02-16 10:31	Peter Kuemmel	Status	resolved => feedback
2013-02-16 10:31	Peter Kuemmel	Resolution	fixed => reopened
2013-02-16 10:49	Mika Fischer	Note Added: 0032317
2013-02-16 10:49	Mika Fischer	Status	feedback => assigned
2013-10-28 04:30	Peter Kuemmel	Severity	minor => feature
2013-10-28 04:30	Peter Kuemmel	Status	assigned => backlog
2013-10-28 04:30	Peter Kuemmel	Fixed in Version	CMake 2.8.11 =>
2014-03-07 11:49	Ben Boeckel	Note Added: 0035339
2014-03-07 11:52	Ben Boeckel	Note Added: 0035340
2014-08-04 16:49	Colin D Bennett	Note Added: 0036547
2015-06-26 12:56	Scott Kevill	Note Added: 0038992
2015-10-06 15:31	James Johnston	Note Added: 0039523
2016-06-10 14:28	Kitware Robot	Note Added: 0042218
2016-06-10 14:28	Kitware Robot	Status	backlog => resolved
2016-06-10 14:28	Kitware Robot	Resolution	reopened => moved
2016-06-10 14:31	Kitware Robot	Status	resolved => closed

Notes
(0032202) Mika Fischer (reporter) 2013-02-05 16:53	Same issue applies to include directories. Fixed in patch v2.

(0032241) Peter Kuemmel (developer) 2013-02-09 06:09	The initial ninja generator implementation has used many (only?) relative paths (not only for source files). As I could remember this was the root of several bugs which are fixed now. I fear that changing the default for paths opens a can of worms. Best would be do a complete review of paths used in the ninja generator, and have a look at the patches of already fixed bugs.

(0032242) Mika Fischer (reporter) 2013-02-09 06:42	Do you have an example? I just went through the closed Ninja bugs here and could not find anything. I would have thought that absolute paths make things simpler and more robust... Further, I'm not changing any default. Just the way source files and include directories are passed to the compiler. Everything else should not be affected by this.

(0032311) Peter Kuemmel (developer) 2013-02-16 08:17	Thanks, commited you patch: http://public.kitware.com/pipermail/cmake-commits/2013-February/014499.html [^]

(0032315) Peter Kuemmel (developer) 2013-02-16 10:31	I've reverted the patch. As I feared, after touching the paths dependency tracking is broken and I also see a lot of empty calls.

(0032317) Mika Fischer (reporter) 2013-02-16 10:49	I see. Unfortunately I don't have the time to delve deep enough into the Cmake code to try to properly fix this and I'm sure there are more important issues for you to work on as well. But maybe we could leave this bug here to give someone else who wants to make cmake + ninja + vim work better together a starting point?

(0035339) Ben Boeckel (developer) 2014-03-07 11:49	I can't reproduce this anymore. I don't know whether Ninja or Vim got smarter, but sitting in the source tree with an external build tree gets me to the right place and the same after doing ":cd src" and another build. FWIW, I'm also using "ninja -C $dir", so maybe ninja knows to DTRT in this case; are you doing the equivalent of "cd $dir && ninja"?

(0035340) Ben Boeckel (developer) 2014-03-07 11:52	Actually, it seems Vim and Ninja got smart. The actual output is: /home/boeckb/code/$proj/src/src/path/to/file.h:40:2: error: #error foo and the QuickFix window shows and gets to the right place: src/path/to/file.h:40:2: error: #error foo After the ":cd", Vim strips off another leading path component. vim-enhanced-7.4.179-1.fc20.x86_64 ninja is 1.4.0.git

(0036547) Colin D Bennett (reporter) 2014-08-04 16:49	This is an issue for me in an IDE as well (Eclipse and Freescale CodeWarrior). Because the compiler is given relative paths to the source files, the error and warning messages also contain these relative paths. But because I'm using an out-of-source build, where the build directory may be "../_build" relative to the source directory (i.e. the output directory is a sibling of the source directory), the relative paths to source files are given relative to this out-of-source build directory. So they look like "../myproject/blah.c" and the IDE is confused. I implemented a crude workaround by writing a Python script which sits as a "proxy" interposed as the compiler in CMake. My toolchain file forces the CMAKE_C_COMPILER and CXX compiler to call PYTHON_EXECUTABLE and pass my filter script as the first argument. This Python script acts as a filter, resolving any relative file paths in warning/error messages into absolute file paths. How hard would it be to expand all file paths to absolute paths before calling external tools? Or resolve to absolute paths early and then CMake could always handle files as absolute paths internally? You could always make a file path relative to the source directory again, so it's essentially a reversible process (except if the relative path is "non-normalized" in that there are redundant ../foo/.. elements etc.).

(0038992) Scott Kevill (reporter) 2015-06-26 12:56	This is more serious than just inconsistent error messages. It causes gcc to store relative paths for the debug info directory paths inside executables, which means gdb can no longer find the original source files. It's especially bad for building RPMs where rpmbuild is automatically extracting the debuginfo and original source files into separate RPMs to store at a different install location (ie. /usr/src/debug/package/....). This completely breaks when relative paths are generated. How does this break dependency tracking if absolute paths are only being passed to the compiler?

(0039523) James Johnston (developer) 2015-10-06 15:31	This is an issue in another IDE as well: Atmel Studio. Although CMake doesn't support Atmel Studio project generation, I wrote some custom CMake code for generating these projects and putting them in the build tree for an out-of-source build. Everything works great, except warnings and errors with relative paths are being incorrectly resolved to absolute paths by the IDE.

(0042218) Kitware Robot (administrator) 2016-06-10 14:28	Resolving issue as `moved`. This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

Relationships