microsoft / microsoft/vscode-cmake-tools

Support IntelliSense for Symlinked Sub-Directories (Multi-Root Workspace)

Open
#1,371 0 comments 3 reactions 0 assignees View on GitHub
embedded Feature: configure Feature: cpptools integration investigation needed
Dominant language
TypeScript
Stars
1.7k
Forks
546
Avg merge
2d 16h
Merged PRs (30d)
32

Description

### Brief Issue Summary

My repo has a flat structure with several lib dirs (call them `lib1`, `lib2`, etc.) and several exe dirs (call them `exe1`, `exe2`, etc.). The exe dirs each target different architectures, so I've setup a VSCode multi-root workspace so I can build several different exe's using their own separate `CMakeLists.txt`s, `build` dirs, and `toolchain.cmake`s. Since some of the lib dirs are used across multiple exe dirs, I've symlinked those top-level lib dirs as subdirs of the exe dirs, so they can be `add_subdirectory(...)`'d and then altered by the exe's `CMakeLists.txt` with calls to `target_compile_definitions(lib1 ...)`, etc. This allows different exes to use the same libs but compile them with different compile defs. It's a nice workflow.

**TLDR**: My problem is that the symlinked common lib dirs don't use their parent workspace folder's CMake intellisense settings. For example, `#ifdef` sections aren't properly grayed out. This is because when the files inside symlinked dirs are opened, VSCode follows the symlink instead of treating it like a regular file.

### Expected:

1. Make a multi-root workspace
2. Symlink a dir from elsewhere in the filesystem to make it a symlinked subdir of one of the workspace folders
3. In that workspace folder's `CMakeLists.txt`, add `add_subdirectory(symlinked_dir)` and `target_compile_definitions(symlinked_dir PUBLIC SOME_DEF)`
4. Make CMake Tools the intellisense provider, i.e.- `"C_Cpp.default.configurationProvider": "ms-vscode.cmake-tools"`
5. Open a source file in the symlinked subdir. The section under `#ifdef SOME_DEF` should be lit up, while the `#else` branch should be grayed out.

### Apparent Behavior:

1. Make a multi-root workspace
2. Symlink a dir from elsewhere in the filesystem to make it a symlinked subdir of one of the workspace folders
3. In that workspace folder's `CMakeLists.txt`, add `add_subdirectory(symlinked_dir)` and `target_compile_definitions(symlinked_dir PUBLIC SOME_DEF)`
4. Make CMake Tools the intellisense provider, i.e.- `"C_Cpp.default.configurationProvider": "ms-vscode.cmake-tools"`
5. Open a source file in the symlinked subdir. IntelliSense settings are not used. This is likely because VSCode follows the symlink.

### CMake Tools Log

There aren't any logs spit out by `CMake/Build`. Maybe this would be better as a `Microsoft C/C++` extension issue?

### Developer Tools Log

How do I get that?

### Platform and Versions

- **Operating System**: Win10 Remote-SSH'd into Ubuntu 20.04
- **CMake Version**: 3.16.3
- **VSCode Version**: 1.47.1
- **CMake Tools Extension Version**: 1.4.1
- **Compiler/Toolchain**: Multiple (`arm-none-eabi`, `arm-linux-gnueabihf`, x86, etc.)

### Other Notes/Information

None.

Contributor guide

Open the contributing guide

Research direction

Start by reproducing the multi-root workspace setup with symlinked directories, the workspace CMakeLists.txt, toolchain.cmake, and CMake Tools as the configuration provider. Trace how CMake Tools supplies IntelliSense settings for files opened through symlinked paths; done means SOME_DEF is applied so the #ifdef branch is active and the #else branch is grayed out.

Written by the indexing model from the issue text.

Assessment

Tech stack
cmake, cpp, vscode
Domain
build-system, developer-experience, tooling
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.