Enable/disable CMake Tools at folder, workspace or user level

[danniesim]

This change addresses items #2338, #3278, #3170 and #1069

The following changes are proposed:

Add a setting that allows users to disable CMake Tools at the folder (aka resource) scope.

The purpose of this change

• Fixes CMake Tools try to configure IntelliSense for Non-CMake projects #2338
• Allow users to turn off CMake Tools for multi-root workspaces where not all roots contain CMake projects.
• Soothe my soul, as my pet peeve is seeing a Python root appear under CTest because CMake Tools is enabled for all roots in a workspace.

Other Notes/Information

I am dogfooding this change with my multi-root workspace with Python, Fortran, Node.JS and C++ CMake projects.

So far, so good.

Edit 1:

• Fix: Hide the CMake Tools Sidebar Button when no CMake folders are enabled.
• Fix: Select the first enabled folder if the active folder is disabled.
• Fix: Dispose the subscription to the enabled setting before adding another.

Edit 2:
I have tested it in multi-root Node.JS, Python, C++ and Fortran projects, and it's working great.

Edit 3:

• Fixes Disable auto popup to select CMakeLists.txt #3278
• Fixes The logic of the feature —— "select CMakeLists.txt" #3170 via a more intuitive "Disable for folder" paradigm. Also, unlike cmake.ignoreCMakeListsMissing, this prevents folders from appearing in under CTest in the Test Explorer.
• Fixes Ignore some root folders in a multi-root workspace #1069

[danniesim]

@gcampbell-msft Would love some feedback on this. :) I've been using this branch and it works great for me.

[gcampbell-msft]

Hi @danniesim, before reviewing this PR, we'd like to understand more about these scenarios and why setting the cmake.configureOnOpen and other types of settings don't already handle this.

To my knowledge, the popup should appear for whether the cmake tools extension should configure, and a user can simply say "no" to this, and then answer the follow-up prompt for when it should honor that setting, and then doesn't that stop the cmake tools extension from trying to configure?

I'd love to discuss this and understand more about this. Thanks!

[gcampbell-msft]

@danniesim Curious to have your feedback from the above message.

Also, I'm curious about your thoughts on whether this PR #3703 fully solves this issue, or only partially.

My initial thoughts are that we already have settings that can be used to determine this, and my initial reaction to a setting that fully disables the extension is that I worry it could get set in the user level, and then disable CMake capabilities on Cmake projects by accident.

Instead, I think it might be better to instead use the PR I referenced above, and if that doesn't solve it all, we could make slight modifications that check if there is any CMake Project that has a CMakeLists.txt defined. If there are none, do like your PR suggestsions, but instead of using the setting to determine it, use the existence of a defined CMakeLists.txt.

More than willing to discuss this or have iterations, but looking forward to your feedback. Thanks!

[danniesim]

@gcampbell-msft The Orta.vscode-jest extension does a similar disable for folder. I see your point: we do not want users to accidentally disable the extension at user scope. I presume VSCode does not allow a setting to exist only at folder scope?

#3703 does not help with non-Cmake projects appearing in the CTests explorer. That said, we can make this.addTestExplorerRoot(project.sourceDir); in ctests.ts run only when cmake.ignoreCMakeListsMissing is false. I am not sure if it will break anything as from what I've seen, the CTest code assumes that all roots are added and that all of them are CMake projects.

[gcampbell-msft]

@danniesim I'm revisiting this, and I'm trying to wrap my head around all the cases that you're seeing this happen.

From what I can tell, if users set cmake.configureOnOpen to false, and cmake.ignoreCMakeListsMissing to true, and cmake.ctest.testExplorerIntegrationEnabled to false, wouldn't this cover all of your cases?

I do notice that cmake.ctest.testExplorerIntegrationEnabled is at the user level, so my above assumption may not be true, but I'm just trying to understand what about the current support doesn't work for this, so that I can think through a way to get the outcome you want, without a possibly user level setting that disables the extension, if possible.

Also, notice the changes I've made to #3703

[danniesim]

Yes, you nailed that one. There is an unpopulated CTest stub for every project in a workspace regardless if ignoreCMakeListsMIssing is true or false. e.g. Even if a root is a Python project, it will have a CTest stub. You can see this in action by adding a Python project to a workspace with CMake projects. Also, it's unintuitive to set 3 settings to the right combination just to get one feature - which is simply to tell the CMake extension that a project root in a multi-root workspace is not a CMake project hence the extension should be disabled for that project root. The key here is that in multi-root, multi-language workspaces, we want it to be easy to tell the extension which roots are CMake and which are not. We are getting warmer with #3703. However, we want also to find a solution for configuring a multi-root, multi-language workspace and not just "on open".

[gcampbell-msft]

@danniesim Could you possibly send me a repro project / workspace to test with? I'd love to test this and while I could create miy own, it'd be good to ensure we have the same project setup. I'd like to investigate with, rather than using a setting to solve the ctest stub issue, simply determine based on whether we have a valid CMake Project (whether or not we actually have a CMakeLists.txt that is set up for the extension for that folder) to determine whether we should integrate ctest and the test explorer. Thanks.

[danniesim]

@gcampbell-msft I have pushed a commit into this branch with a new multi-language workspace in the test folder.

Below is a gif I made to illustrate the UX issues we are discussing.