Construct the driver. Concrete instances should provide their own creation routines.
File compilation terminals. This is a map, rather than a single terminal instance for two reasons:
The key of each terminal is generated deterministically in runCompileCommand()
based on the CWD and environment of the compile command.
The currently running process. We keep a handle on it so we can stop it upon user request
The current Kit. Starts out null, but once set, is never null again.
We do some separation here to protect ourselves: The _baseKit property
is private, so derived classes cannot change it, except via
_setBaseKit, which only allows non-null kits. This prevents the derived
classes from resetting the kit back to null.
The environment variables required by the current kit
Subscribe to changes that affect the CMake configuration
The CMAKE_BUILD_TYPE to use
The arguments to pass to CMake during a configuration according to the current variant
Environment variables defined by the current variant
Determine if we set BUILD_SHARED_LIBS to TRUE or FALSE
Get the vscode root workspace folder.
Returns the vscode root workspace folder. Returns null if no folder is open or the folder uri is not a
file:// scheme.
Directory where build output is stored.
The CMake cache for the driver.
Will be automatically reloaded when the file on disk changes.
The ID of the current compiler, as best we can tell
Path to copy compile_commands.json to
Get the current build type, according to the current selected variant.
This is the value passed to CMAKE_BUILD_TYPE or --config for multiconf
List of executable targets known to CMake
The options that will be passed to expand.expandString for this driver.
Get the name of the current CMake generator, or null if we have not yet
configured the project.
Directory where the targets will be installed.
Is the driver busy? ie. running a configure/build/test
Path to where the root CMakeLists.txt file should be
The source directory, where the root CMakeLists.txt lives.
List of targets known to CMake
Execute pre-configure/build tasks to check if we are ready to run a full configure. This should be called by a derived driver before any configuration tasks are run
Remove the prior CMake configuration files.
Do any necessary disposal for the driver. For the CMake Server driver, this entails shutting down the server process and closing the open pipes.
The reason this is separate from the regular dispose() is so that the
driver shutdown may be awaited on to ensure full shutdown.
Check if we need to reconfigure, such as if an important file has changed
Perform a clean configure. Deletes cached files before running the config
The output consumer
Dispose the driver. This disposes some things synchronously, but also
calls the asyncDispose() method to start any asynchronous shutdown.
Do the configuration process for the current project.
The exit code from CMake
Get the configure environment and apply any needed substitutions before returning it.
Picks the best generator to use on the current system
Get the environment variables that should be set at CMake-configure time.
Get the environment and apply any needed substitutions before returning it.
Get the environment variables required by the current Kit
Launch the given compilation command in an embedded terminal.
The compilation command from a compilation database to run
Change the current kit. This lets the driver reload, if necessary.
The new kit
Change the current options from the variant.
The new options
Stops the currently running process at user request
Asynchronous initialization. Should be called by base classes during their initialization.
Generated using TypeDoc
Base class for CMake drivers.
CMake drivers are separated because different CMake version warrant different communication methods. Older CMake versions need to be driven by the command line, but newer versions may be controlled via CMake server, which provides a much richer interface.
This class defines the basis for what a driver must implement to work.