Support arguments for environment setup script

[SimonMarynissen]

Thanks for the great plugin. I have to setup my build folder in a particular way, so I need a way to run a custom command just before the configure command. It would be great that this is run together with the configure step. How would I add such a step?

To be more concretely, how would I achieve a workflow like the following:

mkdir ${cmake.buildDirectory}

# this can be any other command
conan install ${workspaceFolder} --build=missing -s build_type=${variant:buildType}

cmake -GNinja ${workspaceFolder}

ninja all

Everything works when I do this in a terminal, it is also integrated into cmake-tools except for the custom command, which I have to manually execute each time when I configure.

[andreeis]

You can point "environmenSetupScript" (in your kit definition) to a script that runs the command. This will make sure that the script is run every time the kit is loaded (when VSCode opens your project or when you re-select the kit). It will not be run every time before configure, but since the environment changes are persisted you might need it to be run once in a VSCode session. Let us know if this doesn't help with your scenario.

[SimonMarynissen]

I tried the following two things: "environmentSetupScript": "conan install ${workspaceFolder} --build=missing -s build_type=${variant:buildType}"

and the same, but with a script file with command:

"environmentSetupScript": "setup.sh"

where setup.sh is in the same folder as cmake-kits.json (.vscode)

Both didn't work. Am I missing something?

Bear in mind that I need different setup depending on variants and on a file in the workspace folder.

[andreeis]

The second scenario is the one we support (path to a scrip file instead of a plain command). It needs to be a full path and you can use variables as ${workspaceFolder} or ${variant:debug} for example to construct that full path.

Give us more details about this: Bear in mind that I need different setup depending on variants and on a file in the workspace folder. especially about on a file in the workspace folder. If this were depending only on variants, you can create a script for each variant, have them share the same name except the variant names in the same place in the string and then reference with the variant synax.

Let us know how this works for you.

[SimonMarynissen]

It doesn't seem to work with "environmentSetupScript": "${workspaceFolder}/setup.sh" and setup.sh in the correct folder.

I need this setup.sh be run in build directory, with different parameters (depending on variants) for each build folder.

My build directories are "cmake.buildDirectory": "${workspaceFolder}/build/${variant:buildType}-${variant:graphicsBackend}-${buildKit}",

So they take all the variants in account. Making a script for each variant is cumbersome and not ideal (e.g., a few variants with each 4 options can quickly get a lot different setups)

Btw, I can't find environmentSetupScript in the documentation.

[andreeis]

Yes, we are going to explain environmentSetupScript in our documentation, it is a bit out of date regarding some of the new support that's been implemented in the last year.

Currently, the environment setup script is run from its own path. We are going to fix this so that someone can specify where to run the script from.

So, in the meantime, you can place your script in the build folder, point to the build folder instead of the main root workspace folder. Since you have so many build folders, I'm thinking that you can create a special CMake "install" target that would copy setup.sh from the workspace to the current build folder. Let us know if anything changes if you do this.

But before spending the time to try writing this target, maybe copy it manually (see if it needs any command change caused by the migration to a different location) and give it a try once to verify the concept. Maybe this idea of workaround won't work in the end.

Another thing we can look at is the possibility for the user to pasts arguments to the environment setup script. We'll keep you posted with everything we will do to improve the kit environmentSetupScript user scenario.

[SimonMarynissen]

That's nice to hear.

Running the commands just in a terminal works fine. So, I will just run the command manually for now.

[Turtwiggy]

Hello, I am trying to use the "environmentSetupScript " to call a simple .bat script (similar use case to above) e.g. echo Hello Should I see any output in the terminal to verify that this script gets called?

[github-actions[bot]]

This issue is now marked as 'stale-old' due to there being no activity on it for the past 720 days. Unless the 'stale-old' label is removed or the issue is commented on, this will be remain open for at least 14 days and then it may be closed. If you would like to make this issue exempt from getting stale, please add the 'stale-exempt' label.

[gernika007]

This would be helpful.

[KorkiFork]

Hi,

I have previously opened the request #3418 regarding this topic, but never followed up on this original post. Please implement this feature.

E.g. Calling MSVC environment setup scripts would benefit a lot from being able to provide also arguments to it.

[emodric1]

Providing arguments to the environmentSetupScript in Kits definition would really be helpful when initializing the environment. This option would be of great benefit.

[zoro-io]

Commenting for support. Please get a fix on this.