Bug 342800

Summary: kdevelop incorrectly interprets paths in cmake output
Product: [Applications] kdevelop Reporter: Eugene Shalygin <eugene.shalygin+bugzilla.kde>
Component: Build tools: CMakeAssignee: kdevelop-bugs-null
Status: RESOLVED DUPLICATE    
Severity: normal CC: aspotashev, kfunk
Priority: NOR    
Version: git master   
Target Milestone: 4.7.1   
Platform: Gentoo Packages   
OS: Linux   
Latest Commit: Version Fixed In:

Description Eugene Shalygin 2015-01-13 16:37:20 UTC
When CMake outputs an error in CMakeLists.txt it uses relative paths. They are related to the root CMakeLists.txt as I understand. However, KDevelop interprets them as related to the root build dir. In case of out-of-source builds they do not match and error navigation does not work.

Reproducible: Always

Steps to Reproduce:
Example CMake output:
CMake Error at base/applications/KDE/plasma/sprint_runner/CMakeLists.txt:4


Actual Results:  
When clicking this line in errors view, KDevelop opens ${CMAKE_BINARY_DIR}/base/applications/KDE/plasma/sprint_runner/CMakeLists.txt

Expected Results:  
KDevelop opens ${CMAKE_SOURCE_DIR}/base/applications/KDE/plasma/sprint_runner/CMakeLists.txt

I'm using cmake 3.1.0
Comment 1 Kevin Funk 2015-01-13 16:56:13 UTC
Known.

In fact, given the CMake error output is it impossible to find out what the absolute path of the file is. I've asked the CMake guys several times to print absolute paths for stack traces like this, but noone stepped up implementing it. We need to patch CMake in order to get this right.

One thing we need to fix though: We shouldn't open a new view for a file which doesn't exist when clicking on that error line. On my TODO.
Comment 2 Eugene Shalygin 2015-01-13 17:06:07 UTC
Thanks for the info! Is there any bug on cmake to vote or to do something? 
Could you then, please, implement a workaround: check if a file exists with path counted from CMAKE_BINARY_DIR and if not try to find it in CMAKE_SOURCE_DIR?
Comment 3 Kevin Funk 2017-01-16 18:18:57 UTC

*** This bug has been marked as a duplicate of bug 321982 ***