Different cmake executable per kit?

[reusing-code]

Is it possible to somehow change the used cmake executable per kit?

I know that there is the cmake.cmakePath config option, but this only works on a workspace level. And as far as I can see there is no option to define the cmake executable in the kit itself.

Rationale: I'm trying to cross compile a project for a specific embedded platform. It requires a special cmake binary to compile correctly. But I also want to compile it for my local system, with the normal system cmake. It would be very handy to be able to switch between these two configurations inside a workspace (my current workaround is using two workspaces for the same source repo).

[MatthiasMose]

I stumbled across the same problem and have no solution yet. I use the "environmentSetupScript" variable inside cmake-kits.json to prepare the environment. Inside this script the correct cmake location is added to the path and the necessary variables are set.

Unfortunately CMake Tools does not use the executable delivered with the toolchain. I'm also not able to expand the variables set in our script inside settings.json ("cmake.cmakePath": "${env:OECORE_NATIVE_SYSROOT}/usr/bin/cmake") to enforce it.

[alan-wr]

@MatthiasMose How can you make environmentSetupScript works?

I try it like:

1. create /a/b/c/a.sh file and it's content like:

export OECORE_NATIVE_SYSROOT="abc3"
OECORE_NATIVE_SYSROOT="abc3"

2, add kit in cmake-tools-kits.json like:

  {
    "name": "my test kit from sdk",
    "environmentSetupScript": "/a/b/c/a.sh",
    "toolchainFile": "/a/b/c/a/toolchain.cmake"
  }

3, update set on settings.json "cmake.cmakePath": "${env:OECORE_NATIVE_SYSROOT}/usr/bin/cmake"

I try switch kit, and restart VS code, CMake: Clean.

The cmakepath still is /usr/bin/cmake, not as "abc3/usr/bin/cmake".

[bobbrow]

@alan-wr The environment created for your build is not shared with the environment used to resolve VS Code settings. That's probably why it does not appear to work.

[MatthiasMose]

@alan-wr I'm sorry for the misunderstanding. It does not work for me.

[alan-wr]

@bobbrow I see. Thx. @MatthiasMose That's fine.

[mbodmer]

Same Problem here. The CMake executable is depending on the kit for cross compiling (e.g: Yocto SDK). Either it should be definable at the kit level or in the settings like so: "cmake.cmakePath": ${workspaceFolder}/xyz/${buildKit}/abc/usr/bin/cmake

[mbodmer]

I think it would be best if there is a new cmakePath setting in the kit definition cmake-kits.json which should be used by this kit build. This setting should act as an overlay to the generall cmake.cmakePath setting in settings.json which could still point to the system CMake. For now this keeps me from being able to build for multiple kits (embedded targets with a Yocto SDK). This would really be desirable.

[rpavan21]

+1 for this feature request.

[nych]

i've got a similar problem myself, +1 for this feature request!

[HispidaBytes]

Any news for this feature request? I've have the same problem with a cross-toolchain I'm using 😔 Is there a workaround that can be used ?

[strncpy]

Until this issue gets fixed nicely, in some setups a workaround might be to have wrapper script the chooses the proper cmake binary, e.g.:

"cmake.cmakePath" : "cmake-wrapper" [in settings.json]

and a cmake-wrapper that checks if a toolchain has been sourced by the environmentSetupScript for the kit:

#!/bin/bash

if [ -v OECORE_NATIVE_SYSROOT ]; then
    exec ${OECORE_NATIVE_SYSROOT}/usr/bin/cmake "$@"
else
    exec cmake "$@"
fi

Don't forget to chmod +x cmake-wrapper so that it becomes an executable.

[fredrikbondesson]

We are also using a cross-toolchain based om Yocto SDK, any updates on this issue? It is something that would be really useful. (I have not yet tried out the workaround suggested by strncpy above)

BTW is it possible to "vote" for this feature request somehow?

[bobbrow]

any updates on this issue?

Sorry, not yet. This issue was created before we invested in CMakePresets.json. I recommend you take a look at the documentation for presets since it does provide a way to set a different cmake executable per configuration. If you have any issues with that, please open a new issue and we can handle that as a bug which will have higher priority than adding a new feature to the Kits (which we would like to deprecate).