Option to resolve build diagnostics relative to workspace folder

[i-ky]

Brief Issue Summary

It is a known problem that achieving reproducible builds with CMake requires hacks and workarounds, especially if compiler in use does not support -ffile-prefix-map. In our project we apply some trickery to ensure that compiler is always invoked from the source root with a relative path to source file. As a result of that, compiler prints all errors and warnings with paths relative to the source root instead of absolute paths or paths relative to build directory:

[build] some/path/relative/to/source/root/foo.cpp:12:2: error: #error test
[build]  #error test
[build]   ^

This confuses CMake Tools, if extension detects that path is relative, it appends it to build directory. In Problems tab we see something like:

foo.cpp build/directory/some/path/relative/to/source/root
#error test GCC [12, 2]

Some relevant code: https://github.com/microsoft/vscode-cmake-tools/blob/8faa5dad3f7a07f7ddc83f069e1ce1c88fee3a2d/src/cmake-tools.ts#L912 https://github.com/microsoft/vscode-cmake-tools/blob/8faa5dad3f7a07f7ddc83f069e1ce1c88fee3a2d/src/diagnostics/build.ts#L43 https://github.com/microsoft/vscode-cmake-tools/blob/8faa5dad3f7a07f7ddc83f069e1ce1c88fee3a2d/src/diagnostics/build.ts#L71 https://github.com/microsoft/vscode-cmake-tools/blob/8faa5dad3f7a07f7ddc83f069e1ce1c88fee3a2d/src/diagnostics/build.ts#L82 https://github.com/microsoft/vscode-cmake-tools/blob/8faa5dad3f7a07f7ddc83f069e1ce1c88fee3a2d/src/util.ts#L127-L131

Expected:

We need some sort of configuration option to be able to resolve compiler diagnostics relative to the source root.

Apparent Behavior:

Currently, diagnostics are reported with wrong file path and cannot be opened by clicking on them.

Unable to open 'foo.cpp': Unable to read file '/workspace/folder/build/directory/some/path/relative/to/source/root/foo.cpp' (Error: Unable to resolve non-existing file '/workspace/folder/build/directory/some/path/relative/to/source/root/foo.cpp').

Platform and Versions

• Operating System: Ubuntu 16.04
• CMake Version: 3.15.5
• VSCode Version: 1.47.3
• CMake Tools Extension Version: 0.29.0
• Compiler/Toolchain: GCC 4.9.3

[bobbrow]

If you would like to add a new setting (e.g. cmake.buildDiagnosticsRootPath) and do a PR for this feature, we would be happy to review and accept it.

[i-ky]

We managed to work around the issue using

"cmake.buildTask": true

in settings.json and a custom build task in tasks.json:

{
    "label": "Build selected configuration",
    "group": {
        "kind": "build",
        "isDefault": true
    },
    "type": "shell",
    "command": "/bin/bash",
    "args": [
        "-c",
        "${command:cmake.tasksBuildCommand}"
    ],
    "problemMatcher": "$gcc"
}

This way we gained control over problemMatcher and now it seems to be doing the right thing.

I have to say it took us a while to figure out how cmake.buildTask was supposed to work, it is a pity that #647 got merged without documentation update.

[dagar]

I've come across the same problem with the current workaround of using a custom build task that sets a relative file location for the problemMatcher.

        {
            "label": "build",
            "type": "shell",
            "command": "/bin/bash",
            "args": [
                "-c",
                "${command:cmake.tasksBuildCommand}"
            ],
            "options": {
                "cwd": "${command:cmake.buildDirectory}"
            },
            "group": {
                "kind": "build",
                "isDefault": true,
            },
            "problemMatcher": {
                "base": "$gcc",
                "fileLocation": ["relative", "${command:cmake.buildDirectory}"]
            }
        },

Is this not in general the right thing to do with cmake? With Ninja it doesn't appear to be possible to have non-relative paths.

[github-actions[bot]]

This issue is now marked as 'stale-old' due to there being no activity on it for the past 720 days. Unless the 'stale-old' label is removed or the issue is commented on, this will be remain open for at least 14 days and then it may be closed. If you would like to make this issue exempt from getting stale, please add the 'stale-exempt' label.

[v-frankwang]

@i-ky We have attempted to verify this issue on CMake tools: v1.19.45, but we don't have detailed reproduction steps to reproduce it. Are you able to go and verify that the issue is fixed?