Plugin doesn't handle `cmake.sourceDirectory` changes properly

[Luke-zhang-mchp]

Brief Issue Summary

I have a workspace structure that looks like this:

.
├── cmake-simple-demo
│   └── CMakeLists.txt
├── cmake-simple-demo_copy
│   └──  CMakeLists.txt
└──  cmake-simple-demo_copy_1
    └──  CMakeLists.txt

When VSCode is first opened, the CMake view is not listed under "Open View" and many CMake commands are missing. This is to be expected, since the default value of cmake.sourceDirectory is ${workspaceFolder}, but there is no CMakeLists file there. However, when I give the preference a value, the commands are still missing, and the CMake view is still not listed. They only show once I reload the IDE.

A related issue: when there is only 1 path in the cmake.sourceDirectory array, the path and name of the folder is automatically assumed to be the workspace folder, which is not always true.

Related again: when there is an array of directories in the array, and one new entry is added, the path and name of the folder is also assumed to be the workspace folder. This is fixed on reload, and also does not occur if more than 1 entry is added at once.

CMake Tools Diagnostics

Debug Log

Additional Information

I did some preliminary digging. The second issue is caused by this line: https://github.com/microsoft/vscode-cmake-tools/blob/main/src/projectController.ts#L279. It should instead always return this.sourceDir.

The last issue is caused by this line: https://github.com/microsoft/vscode-cmake-tools/blob/main/src/projectController.ts#L279. The parameter value only includes the newly added values, hence why checking for length > 1 is incorrect.

I wanted to make sure there weren't any edge cases I was missing making these changes. For example, CMakeProject.folderPath has a comment that says "For single-project folders, this is the WorkspaceFolder for historical reasons." I haven't looked at the first issue yet.

[Luke-zhang-mchp]

Update: here are the changes I figured were needed to fix these bugs. I'm still unsure about the changes to the folderPath method and related isMultiProjectWorkspace logic

https://github.com/Luke-zhang-mchp/vscode-cmake-tools/compare/main...Luke-zhang-mchp:vscode-cmake-tools:config-change-fix

[Yingzi1234]

@Luke-zhang-mchp We would like to reproduce your problem, please provide a record of the reproduction steps in as much detail as possible. Thank you in advance!

[Luke-zhang-04]

For the first issue:

1. In an empty workspace, create a file in folder/CMakeLists.txt
2. Open the workspace in VSCode, create a .vscode/settings.json file and set "cmake.sourceDirectory": "${workspaceFolder}/folder"
3. In the command palette, you can see the CMake feature set is not enabled (most commands are missing). Reloading the IDE fixes this.

For the second issue, open command palette and run "Select Active Folder". The dropdown option should have title folder, but instead it is the name of the workspace. The path that is displayed next to it is ${workspaceFolder}, but it should be ${workspaceFolder}/folder.

[Yingzi1234]

@Luke-zhang-04 Thank you for your reply! Based on your description of the problem, we have reproduced the problem, but we are not sure if we have reproduced your problem completely, here is a recording of me reproducing the problem, could you help me to confirm if we have reproduced the problem?

[Luke-zhang-mchp]

Hey @Yingzi1234, that doesn't look like what I was trying to get at. Here's the first problem:

https://github.com/user-attachments/assets/e5c31e46-fadb-4e3d-8ffa-8e8ee56d2b1e

as you can see, the CMake view and CMake commands only show up after IDE refresh.

The second problem:

https://github.com/user-attachments/assets/5a966e91-dcc8-4cc8-9d98-c5cbe9a07aaa

In the select active folder command, the names of the project are sometimes wrong. This is the case when either:

• There is only 1 valid project in the cmake.sourceDirectory array
• 1 valid project was added to the cmake.sourceDirectory array, in which case the new project is the one with the incorrect name.

Like I said, these were the changes I needed to fix the issue: https://github.com/Luke-zhang-mchp/vscode-cmake-tools/compare/main...Luke-zhang-mchp:vscode-cmake-tools:config-change-fix, but I'm not sure if my changes will break something else or what the "historical reasons" mentioned in the comments are.

[Yingzi1234]

@Luke-zhang-04 Thank you for your reply and help! With your help, we reproduced both of your issues and we have turned this issue into a bug @gcampbell-msft The user has a total of two issues that we can reproduce, here are the detailed reproduction steps as well as the information, the user has already provided the fix for the PR on his own but he doesn't know how to do the merge, could you provide some help?

The first issue: When CMake. source directory specifies only one subfolder, the list after running CMake: Select Active folder will not show the expected results. Repro steps:

1. Open this folderMyWorkspace.zip(Make sure the test folders have two or more sub-folders)
2. Set “CMake.source directory” to one of the sub-project names.
3. Click F1 to run the command CMake: select active folder and check that the entire list is displayed

Second issue: When an invalid subfolder exists in the CMake.source directory, the list is incomplete after running the CMake: Select Active command Repro steps:

1. Open this folderInheritance.zip (Make sure the test folders have two or more sub-folders)
2. Set the sub-folder's name to the CMake. source directory settings
3. Invalidate one of the lines of code
4. Click F1 to run the command CMake: select active folder and check that the entire list is displayed

[Luke-zhang-mchp]

Just a note: that second issue described in the video recording is actually the opposite of what I had initially intended to fix. For us, we started with cmake.sourceDirectory as an empty array, and then when adding projects to it, the CMake feature set was not activated (i.e could not open CMake view, could not run most CMake commands). However the code needed to fix both issues is the same.

[Yingzi1234]

@Luke-zhang-04 Thanks for the additions, we've changed the status of this issue to Bug, we'll let you know as soon as we have any updates!