The active workspace folder. This controls several aspects of the extension, including:
The CMake Tools backend instances available in the extension. The reason for multiple is so that each workspace folder may have its own unique instance
Watch for text edits. At the moment, this only watches for changes to the
kits files, since the filesystem watcher in the _kitsWatcher
is sometimes
unreliable.
Watches for changes to the kits file
The tree data provider
The status bar controller
The kits available from the user-local kits file
Subscription to workspace changes.
When a workspace is added or removed, the instances of CMakeTools are update to match the new state.
For each workspace folder, a separate instance of CMake Tools is maintained. This allows each folder to both share configuration as well as keep its own separately.
The kits available from the workspace kits file
Adding/removing workspaces should be serialized. Keep that work in a strand.
The CMake Tools instance associated with the current workspace folder, or
null
if no folder is open.
Get both workspace-local kits and user-local kits
The path to the workspace-local kits file, dependent on the path to the active workspace folder.
Get the CMakeTools instance associated with the given workspace folder, or null
The workspace folder to search
Create a new CMakeTools instance for the given WorkspaceFolder
The workspace folder to create for
Ensure that there is an active kit for the current CMakeTools.
false
if there is not active CMakeTools, or it has no active kit
and the user cancelled the kit selection dialog.
Get the current MinGW search directories
Mark a kit to be "kept". This set the keep
value to true
and writes
re-writes the user kits file.
The kit to mark
Load a new CMakeTools for the given workspace folder and remember it.
The workspace folder to load for
Handle workspace change event.
Workspace change event
Remove a kit from the user-local kits.
The kit to remove
Remove knowledge of the given workspace folder. Disposes of the CMakeTools instance associated with the workspace.
The workspace to remove for
Reload the list of available kits from the filesystem. This will also update the kit loaded into the current backend if applicable.
Drop the current kits watcher and create a new one.
Set the active workspace folder. This reloads a lot of different bits and pieces to control which backend has control and receives user input.
The workspace to activate
Set the current kit in the current CMake Tools instance
The kit
User-interactive kit pruning:
This function will find all user-local kits that identify files that are no longer present (such as compiler binaries), and will show a popup notification to the user requesting an action.
This function will not prune kits that have the keep
field marked true
If the user chooses to remove the kit, we call _removeKit()
and erase it
from the user-local file.
If the user chooses to keep teh kit, we call _keepKit()
and set the
keep
field on the kit to true
.
Always returns immediately.
Write the given kits the the user-local cmake-kits.json file.
The kits to write to the file.
Create a new instance of the backend to support the given workspace folder. The given folder must not already be loaded.
The workspace folder to load for
The newly created CMakeTools backend for the given folder
Asynchronously dispose of all the child objects.
Compile a single source file.
The file to compile. Either a file path or the URI to the file. If not provided, compiles the file in the active text editor.
Dispose of the CMake Tools extension.
If you can, prefer to call asyncDispose
, which awaits on the children.
Opens a text editor with the user-local cmake-kits.json
file.
Rescan the system for kits and save them to the user-local kits file
Show UI to allow the user to select an active kit
Wraps an operation that requires an open workspace and kit selection. If there is no active CMakeTools (no open workspace) or if the user cancels kit selection, we return the given default value.
The default return value
The callback
Generated using TypeDoc
A class to manage the extension.
Yeah, yeah. It's another "Manager", but this is to be the only one.
This is the true "singleton" of the extension. It acts as the glue between the lower layers and the VSCode UX. When a user presses a button to necessitate user input, this class acts as intermediary and will send important information down to the lower layers.