Feature Request: Allow to run a (shell script) wrapper for cmake

[emmenlau]

Brief Issue Summary

This issue is slightly related to #809 but not the same. We have a use case where users should not execute cmake directly from the shell, but instead should use a small wrapper bash script. This is due to a number of environment constraints that help isolate the build from the rest of the system.

Everything works perfectly well on all kinds of Unix (Linux, macOS) where shell scripts are executed native. But it breaks on Windows. We use Cygwin bash for implementing the wrapper and that seems not supported. I tried

"cmake.cmakePath": "C:\Scripts\bin\vscode-cmake-wrapper.sh"

and

"cmake.cmakePath": "C:\Cygwin64\bin\bash.exe C:\Scripts\bin\vscode-cmake-wrapper.sh"

but both will not work. Admittedly I did not try a cmd script.

Are there known workarounds? Or could this be implemented, for example by supporting a full command line in "cmake.cmakePath"?

[andreeis]

@emmenlau, thank you for this feature idea. We may not be able to implement this immediately and we will monitor the reactions from the community to evaluate where this fits best in our backlog.

One way we can support this is to extend what "cmakePath" can do, as you stated.

Just to explore all possibilities, if we add a setting to run the "environmentSetupScript" every time before configure and/or build (opposed to what is doing now, being run only when a kit is set or when the project is loaded), would that work? You can try now by resetting your kit (change to a different one then back to the original) before you do the operation that needs this script to be run. If you find that running the kit "environmentSetupScript" each time is causing things to work, then maybe we prefer to implement this support this way.

[emmenlau]

Dear @andreeis , thanks a lot for the nice and positive response!

The environmentSetupScript would not help me, because I do need to wrap the actual call to cmake. The reason is specific to our CI, we can not give full control to the vscode extension but need to intercept and filter certain calls and arguments. This generally works very well for us and gives very good control to users. But it requires that cmake.cmakePath points to a script instead of the actual cmake.

However I have good news: Today evening I tested using a batch (cmd) script on Windows, and that actually works. Now I still have the problem that I do need to set different scripts for cmake.cmakePath on Windows compared to all Unix. But for the time being this is possible with environment variables. And in any case that is not so much a problem of vscode-cmake-tools but rather of VSCode.

We could still leave this issue open as an idea for the future, but my immediate needs are answered for now.

[emmenlau]

The issue is not completely gone but I have sufficient workarounds (as mentioned above) to say that this is not a problem for us any more. Closing the issue as "low relevance"...