# presets: Precedent for IDE implementation of \`cmakeExecutable\`?

**URL:** https://discourse.cmake.org/t/presets-precedent-for-ide-implementation-of-cmakeexecutable/9255
**Category:** Development
**Created:** [October 23, 2023, 4:11pm UTC](https://discourse.cmake.org/t/presets-precedent-for-ide-implementation-of-cmakeexecutable/9255 "2023-10-23T16:11:38Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![gcampbell-msft](https://discourse.cmake.org/user_avatar/discourse.cmake.org/gcampbell-msft/32/3578_2.png) [@gcampbell-msft](https://discourse.cmake.org/u/gcampbell-msft)
#### Post date: [October 23, 2023, 4:11pm UTC](https://discourse.cmake.org/t/presets-precedent-for-ide-implementation-of-cmakeexecutable/9255/1 "2023-10-23T16:11:38Z")

</div>

Hi, everyone.

I’m curious if there is precedent for how `cmakeExecutable` is implemented and used by IDE’s? I assume it’s looking for a direct path to the executable and not a path to a directory. Is there any preferred implementation/usage of this field?

Also, should the `cmakeExecutable` field be resolvable from PATH? For example, if someone simply enters an exe such as “test.exe”, should it check both the source directory and PATH?

Curious to see if there is any precedent or any opinions from Kitware, thanks!

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [October 23, 2023, 6:56pm UTC](https://discourse.cmake.org/t/presets-precedent-for-ide-implementation-of-cmakeexecutable/9255/2 "2023-10-23T18:56:38Z")

</div>

I think I’d expect it to take something that can be used as `argv[0]` to run CMake. This should support a full path or just a name that `PATH` lookup can discover.

---

<div class="post-metadata">

### Author: ![craig.scott](https://discourse.cmake.org/user_avatar/discourse.cmake.org/craig.scott/32/20_2.png) [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [October 27, 2023, 10:15pm UTC](https://discourse.cmake.org/t/presets-precedent-for-ide-implementation-of-cmakeexecutable/9255/3 "2023-10-27T22:15:21Z")

</div>

NOTE: I am not affiliated with Kitware, this is just my own opinion.

My experience with the `cmakeExecutable` presets field across different IDEs was a horrible, frustrating one. First let me say that `CMakePresets.json` should not normally set this field. That file would be provided by the project and checked in along with the source code. You should not typically be hard-coding a choice of CMake executable, that’s something that should be specified by the user, since only they know what is appropriate on their machine. An exception might be in corporate environments with tightly controlled developer machine configs (still not something I’d recommend though). It _may_ be useful in a `CMakeUserPresets.json` file in specific cases, but because of how some IDEs treat this field, you will be constrained by what you can do with it.

My recollection after fighting with this with one of my consulting clients is that Visual Studio (not VS Code) requires whatever you put here to be an executable named `cmake`, and it must have a `.exe` extension, or else Visual Studio will forcibly append that extension. Any name other than `cmake` doesn’t work. This means you can’t put the name of a batch file that wraps the real `cmake.exe`, which was the use case I was ultimately unable to satisfy. Unfortunately, Visual Studio doesn’t give you any other way to override the location of the `cmake` executable when you’re using presets, other than this severely limited implementation of the `cmakeExecutable` field. I believe it does allow you to specify just the name of the executable and it will find it on the PATH.

VS Code and CLion are more flexible and let you specify a full path to whatever file you want in their app settings, including wrappers like shell scripts or batch files. That should mean you don’t need to specify a `cmakeExecutable` field in your presets, but I think VS Code will honour such a presets field if present. I think CLion would ignore that field, since it uses a separate concept of “toolchains” in its settings which are pretty central to the way their system works, but they support an “environment” file which gives you plenty of flexibility.

Not sure if that answers your question, but hopefully it helps.

---

<div class="post-metadata">

### Author: ![gcampbell-msft](https://discourse.cmake.org/user_avatar/discourse.cmake.org/gcampbell-msft/32/3578_2.png) [@gcampbell-msft](https://discourse.cmake.org/u/gcampbell-msft)
#### Post date: [October 30, 2023, 1:38pm UTC](https://discourse.cmake.org/t/presets-precedent-for-ide-implementation-of-cmakeexecutable/9255/4 "2023-10-30T13:38:45Z")

</div>

@craig.scott This is great feedback! Thank you
