Adding configuration option when sh.exe is in PATH.

[RolfNoot]

Cmake configure will complain when sh.exe is in the PATH.

See this discussion on Stackoverflow.

I am adding this to my settings:
"cmake.configureArgs": ["-DCMAKE_SH=CMAKE_SH-NOTFOUND"]

However, the manual states that -D options should never be used with cmake.configureArgs.

How should this be done?

[bobbrow]

We say that it's "not recommended", but we will still pass along any configureArgs we see to CMake. Does it not work if you pass it in the cmake.configureSettings?

{
  "cmake.configureSettings": {
    "CMAKE_SH": "CMAKE_SH-NOTFOUND"
  }
}

[RolfNoot]

Which I mean, using the "cmake.configureSettings" still doesn't work well as it generates the wrong command.

[bobbrow]

Does cmake.configureArgs work for you? Is CMAKE_SH supposed to be :FILEPATH instead of :STRING?

[RolfNoot]

I can't tell with CMake 3.25 but I can tell from 3.12 that using cmake.configureSettings does not work. The problem is that using cmake.configureSettings, the command-line option is evaluated to:
-DCMAKE_SH:STRING=CMAKE_SH-NOTFOUND
while it should evaluate to:
-DCMAKE_SH=CMAKE_SH-NOTFOUND

(see picture above)

[RolfNoot]

Yes, cmake.configureArgs does work. But I also see the build type configuration going wrong which gave me problems:
-DCMAKE_BUILD_TYPE:STRING=Debug

Or is it possible to use CMake options with the type specifier as above?

[bobbrow]

Are you setting CMAKE_BUILD_TYPE in the settings? Our extension expects it to be set in the statusbar or with the "CMake: Select Variant" command. I don't see how setting it as a :STRING could cause a problem though. We've been doing it this way for years.

I don't see CMAKE_SH documented anywhere, so I can't tell if it's expected to be :FILEPATH or not. What error are you getting when it's typed as a :STRING?

[RolfNoot]

About CMAKE_SH, I found it here. The problem is solved with the use of CMake 3.25. I am fine with this.

My concern is actually that this command is formatted incorrectly:
[proc] Executing command: /opt/local/bin/cmake --no-warn-unused-cli -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_C_COMPILER:FILEPATH=/Volumes/Data/VScode/GIT/VSCode_OnethinxPack_macOS/gcc-arm-none-eabi-10.3-2021.10/bin/arm-none-eabi-gcc -DCMAKE_CXX_COMPILER:FILEPATH=/Volumes/Data/VScode/GIT/VSCode_OnethinxPack_macOS/gcc-arm-none-eabi-10.3-2021.10/bin/arm-none-eabi-g++ -S/Volumes/Data/VScode/GIT/Onethinx_Project_Examples/Example_ADC -B/Volumes/Data/VScode/GIT/Onethinx_Project_Examples/Example_ADC/build -G "Unix Makefiles"

Because of -DCMAKE_BUILD_TYPE:STRING=Debug instead of -DCMAKE_BUILD_TYPE=Debug however, I'm no expert on CMake. It's not generating errors either and I am not sure if it works well. I have to do a Clean-Reconfigure after switching Debug<>Release and build multiple times. I am not switching often, so I don't know if this is still a problem.

[bobbrow]

Needing to do a clean configure is not likely because of the typing of CMAKE_BUILD_TYPE.

I suspect the problem is that you are using a single-config generator like Ninja, Unix Makefiles, etc, and are using the default value of cmake.binaryDir which does not handle this well. If you are using a single config generator and you don't want to clean config whenver you change the build type, you need to set cmake.binaryDir to a path that changes with the build type, for example: "${workspaceFolder}/build/${buildType}"

[bobbrow]

And I'm also about to push a PR that will support more control over the typing of configureSettings in case you want to set (or unset) it explicitly. #2868

[RolfNoot]

Thanks, that makes sense. I will use the separate paths as suggested. And I will test the PR when released .

[bobbrow]

1.13.28 which will release tomorrow has support for explicit variable typing. More info here: #1457