MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0013894CMakeCMakepublic2013-02-05 16:372016-06-10 14:31
ReporterMika Fischer 
Assigned ToPeter Kuemmel 
PrioritynormalSeverityfeatureReproducibilityalways
StatusclosedResolutionmoved 
PlatformLinuxOSArchOS Versioncurrent
Product VersionCMake 2.8.10.2 
Target VersionFixed in Version 
Summary0013894: Ninja: generator uses relative paths for source files
DescriptionThis makes it unnecessarily difficult for tools parsing the generated errors to find the referenced file. In particular, jumping to error locations in vim only works when the current directory is the root of the build directory, otherwise the relative paths in the error messages point to the wrong location.

The Unix Makefile generator uses absolute filenames for source files and thus does not suffer from this.

If there's not a strong reason for the current behavior, I would suggest to also use absolute filenames (at least) for source files in the Ninja generator.

A patch that fixes this for me is attached.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filespatch cmake-ninja-absolute-filenames.patch (521) 2013-02-05 16:37
https://public.kitware.com/Bug/file/4634/cmake-ninja-absolute-filenames.patch
patch cmake-ninja-absolute-filenames-v2.patch (1,164) 2013-02-05 16:53
https://public.kitware.com/Bug/file/4635/cmake-ninja-absolute-filenames-v2.patch
Issue History
Date ModifiedUsernameFieldChange
2013-02-05 16:37Mika FischerNew Issue
2013-02-05 16:37Mika FischerFile Added: cmake-ninja-absolute-filenames.patch
2013-02-05 16:53Mika FischerNote Added: 0032202
2013-02-05 16:53Mika FischerFile Added: cmake-ninja-absolute-filenames-v2.patch
2013-02-06 09:22Brad KingAssigned To => Peter Kuemmel
2013-02-06 09:22Brad KingStatusnew => assigned
2013-02-09 06:09Peter KuemmelNote Added: 0032241
2013-02-09 06:42Mika FischerNote Added: 0032242
2013-02-09 07:03Peter KuemmelSummaryNinja generator uses relative paths for source files => Ninja: generator uses relative paths for source files
2013-02-16 08:17Peter KuemmelNote Added: 0032311
2013-02-16 08:17Peter KuemmelStatusassigned => resolved
2013-02-16 08:17Peter KuemmelFixed in Version => CMake 2.8.11
2013-02-16 08:17Peter KuemmelResolutionopen => fixed
2013-02-16 10:31Peter KuemmelNote Added: 0032315
2013-02-16 10:31Peter KuemmelStatusresolved => feedback
2013-02-16 10:31Peter KuemmelResolutionfixed => reopened
2013-02-16 10:49Mika FischerNote Added: 0032317
2013-02-16 10:49Mika FischerStatusfeedback => assigned
2013-10-28 04:30Peter KuemmelSeverityminor => feature
2013-10-28 04:30Peter KuemmelStatusassigned => backlog
2013-10-28 04:30Peter KuemmelFixed in VersionCMake 2.8.11 =>
2014-03-07 11:49Ben BoeckelNote Added: 0035339
2014-03-07 11:52Ben BoeckelNote Added: 0035340
2014-08-04 16:49Colin D BennettNote Added: 0036547
2015-06-26 12:56Scott KevillNote Added: 0038992
2015-10-06 15:31James JohnstonNote Added: 0039523
2016-06-10 14:28Kitware RobotNote Added: 0042218
2016-06-10 14:28Kitware RobotStatusbacklog => resolved
2016-06-10 14:28Kitware RobotResolutionreopened => moved
2016-06-10 14:31Kitware RobotStatusresolved => closed

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

Fixed in patch v2.
(0032241)
Peter Kuemmel   
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   
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   
2013-02-16 08:17   
Thanks, commited you patch: http://public.kitware.com/pipermail/cmake-commits/2013-February/014499.html [^]
(0032315)
Peter Kuemmel   
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   
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   
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   
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   
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   
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   
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   
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.