[Dennis Lambe Jr. (malsyned)]

This change partially addresses items #1936 and #4301

This changes visible behavior & documentation

The following changes are proposed:

Add a new command, cmake.cacheVariable, which can be used in launch.json and tasks.json as a command input, allowing substitution of cache variables defined in CMakeLists.txt or in the configurePresets.cacheVariables property of CMakePresets.json.

The inputs section can be used to pass a CMake cache variable name to cmake.cacheVariable, and that input can in turn be used for variable substitution in property values in the configuration section.

Example:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Debug with J-Link",
            "request": "launch",
            "type": "cortex-debug",
            "executable": "${command:cmake.launchTargetPath}",
            "cwd": "${workspaceFolder}",
            "servertype": "jlink",
            "interface": "jtag",
            "device": "${input:DEVICE}"
       }
    ],
    "inputs": [
        {
            "id": "DEVICE",
            "type": "command",
            "command": "cmake.cacheVariable",
            "args": {
                "name": "DEVICE",
                "default": "rm44l520"
            }
        }
    ]
}

The purpose of this change

To allow CMakeLists.txt to serve as a single point of truth for configuration information specific to the user's project. In my case, for example, I can keep the part number of my project's microcontroller in a CMake cache variable, and use it to populate cortex-debug properties like "device" and "svdFile". The description in #1976 looks to me like it has the same use case in mind, but I bet there are plenty of other situations where this would come in handy.

Other Notes/Information

The referenced issue tickets mention providing access not just to cache variables, but also to environment variables. This PR doesn't address the environment variable part of those feature requests.

[Dennis Lambe Jr. (malsyned)]

I would love to get a maintainer's take on bcbc15e to confirm that 1) I should be doing that and 2) I'm doing it the right way.

[Garrett Campbell (gcampbell-msft)]

Overall, this seems like a good idea and allows people to get variables set in their CMake project, whether from CMakePresets, CMakeLists.txt, or anywhere else. With a couple of small changes, this looks like a good addition with minimal risk. Thanks!

[Dennis Lambe Jr. (malsyned)]

OK awesome.

Looks like the CI is failing on localization. I admit to some wishful mimicry when it comes to that part of the PR. I'll see if I can figure out what the problem is and fix it. Any pointers on what I might be doing wrong would be appreciated.

[Dennis Lambe Jr. (malsyned)]

I pulled in your mac CI flakiness fix, in the hopes of getting a green light.