Unable to open source file outside workspaceFolder from project outline

[bobbrow]

hi @bobbrow, I am using 1.4.2 CMake Tools on macOS, but the issue is still there:

Unable to open 'main.cpp': Unable to read file '/Users/admin/Projects/A/console/Users/admin/Projects/A/src/main.cpp' (Error: Unable to resolve non-existing file '/Users/admin/Projects/A/console/Users/admin/Projects/A/src/main.cpp').

The project structure looks like:

A $ tree -L 2 .
.
├── README.md
├── console
│   ├── build
│   └── CMakeLists.txt
├── src
│   └── main.cpp
└── third-party

with this simple setup:

set(MAIN_SOURCE_DIR "../src")

file(GLOB_RECURSE CPP_HEADERS ${MAIN_SOURCE_DIR}/*.hpp)
file(GLOB_RECURSE CPP_SOURCES ${MAIN_SOURCE_DIR}/*.cpp)

add_executable(
    A
    ${CPP_HEADERS}
    ${CPP_SOURCES}
)

As you can see, the error reports a path with <CMakeLists Dir>+<Absolute Source Path>, which is duplicate and totally wrong.

'/Users/admin/Projects/A/console/Users/admin/Projects/A/src/main.cpp'

Platform and Versions
Operating System:macOS
CMake Version:3.18.4
VSCode Version:1.50.1
CMake Tools Extension Version: 1.4.2
Compiler/Toolchain: Clang 11

Originally posted by @mutoo in #1254 (comment)

[bobbrow]

@mutoo, can you provide a little more information for us? Which folder in the structure you shared is the ${workspaceFolder}? I tried opening both console and src after replicating your folder structure, but am unable to repro on Windows. I'll try again on Linux (I don't have a mac to try right now).

[mutoo]

@bobbrow, the ${workspaceFolder} is the console /Users/admin/Projects/A/console.

[tvb377]

Me too:
I have a folder structure where two source folders are on the same level.
One of them contains the CMakeLists.txt and adds sources also from its sibling.

CMake Tools somehow understands that some source files are located together in another folder, and in the explorer subsumes them in a separate tree entry underneath the target.
But already in the explorer a wrong path to the folder appears: apparently relative to the build directory, but after .... "\Users\name" gets prepended.
When I try to open a file of the library dir (the one not containing CMakeLists.txt), I get the message:
Unable to open 'byte_to_hex.c': Unable to read file 'c:\Users\name\Users\name\srclocal\avrlib\byte_to_hex.c' (Error: Unable to resolve non-existing file 'c:\Users\name\Users\name\srclocal\avrlib\byte_to_hex.c').

Also, the file names communicated to intellisense seem to be wrong.

As you can see, this is on Windows.

[k0pernicus]

Hi everyone,
I have the exact same issue than @bobbrow (EDIT: sorry, it was @mutoo).

If I don't make any mistake, we are following a tutorial to create a sort of graphic engine on multiple platforms, using C++ and SDL: https://marcelbraghetto.github.io/a-simple-triangle/2019/03/02/part-02/

In this part, the author shows how to configure it's own VSCode instance using Cmake and Cmake Tools (vector-of-bool version, not from microsoft), but following the steps VSCode + extensions does not follow the rules and create another full path inside the current workspace folder.

I expect that the configuration of the extensions change, or something we missed, because using the scripts on the console directly works, check the code directly and build the binary.

Setup:

• macOS Catalina 10.15.7
• VSCode 1.50.1
• CMake (twxs) version 0.0.17
• CMake Tools (Microsoft) version 1.5.0

[srpax]

Hi @bobbrow, I also have this problem. I'm also using SDL like @k0pernicus, but I'm not following a tutorial (i.e. issue produced organically). For example, I might have a file structure like:

EDIT: Updated this tree to reflect actual file structure since it may matter.

C:\Users\spaxt\
├── SDL2-2.0.12\
│   └── include\
│       └── SDL.h
└── project-ember\
    ├── include\
    │   └── MbrWindow.h (#includes SDL.h)
    └── CMakeLists.txt 

The add_library/add_executable call in CMakeLists could be using a relative or absolute path of SDL.h, and I still get the follow situation:
(Ember is the name of my project)

Ok, that doesn't look bad, but the part of the path you can't see is "C:\Users", so the whole path resolves as:
C:\Users\Users\spaxt\SDL2-2.0.12\include\SDL.h

Obviously C:\Users\Users doesn't exist:

EDIT: Added relevant CMakeLists.txt content showing how I obtain the SDL.h path:

# SDL2 variables
set(SDL_DIR ${PROJECT_SOURCE_DIR}/../SDL2-2.0.12)
set(SDL_PUBLIC_HEADER ${SDL_DIR}/include/SDL.h)
...
add_library(Ember SHARED ${EMBER_HEADER_FILES} ${EMBER_SOURCE_FILES} ${SDL_PUBLIC_HEADER})

Setup:

• Visual Studio Code 1.50.1
• CMake (twxs) version 0.0.17
• CMake Tools (Microsoft) version 1.5.1
• Other Extensions:
  

[Dyronix]

Would it be possible to receive a patch for this fix, it is blocking our entire workflow ... We have to switch IDE in order to edit our source files and switch back to run the CMake configuration.

A workaround would also do the trick.

[sleiner]

I too would be very happy to have this fixed. If there is anything I can do to help, please reach out @bobbrow :-)

[bobbrow]

Thanks for the offer @sleiner! If you have a repro and can debug the extension as it's building the tree view, that would help us get the information we need to understand the bug. Contribution doc

The line I would set a breakpoint on is here:

vscode-cmake-tools/src/tree.ts

Line 232 in 48c4a33

item.command = {

I suspect that the item.resourceUri is incorrect in this case.

[sleiner]

Thanks for the helpful hint 😊 I actually came up with something that fixes the problem (at least on my Mac with a very simple project). I'll test it with a much larger project at work tomorrow 👍🏻

[andreeis]

@sleiner, your contribution is in 👍. If all goes according to plans, we should release CMake Tools 1.7.2 tomorrow. Until then, here's a vsix with your change, if needed: https://github.com/microsoft/vscode-cmake-tools/actions/runs/814930130.

[sleiner]

Thanks, you two 🙌🏻