# Manually setting \`CMAKE\_MAKE\_PROGRAM\` before calling \`project()\`
**URL:** https://discourse.cmake.org/t/manually-setting-cmake-make-program-before-calling-project/10967
**Category:** Usage
**Created:** [June 6, 2024, 8:43pm UTC](https://discourse.cmake.org/t/manually-setting-cmake-make-program-before-calling-project/10967 "2024-06-06T20:43:08Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@Fabrice\_de\_Gans](https://discourse.cmake.org/u/Fabrice_de_Gans)
#### Post date: [June 6, 2024, 8:43pm UTC](https://discourse.cmake.org/t/manually-setting-cmake-make-program-before-calling-project/10967/1 "2024-06-06T20:43:09Z")
Assuming the generator is `Ninja` and there is no system-wide installation of `ninja` (i.e. not in `PATH`), consider the following code:
```cmake
# Doing work to download/install a pinned ninja version in here.
set(CMAKE_MAKE_PROGRAM "/path/to/ninja" CACHE FILEPATH "Path to ninja binary" FORCE)
project(project_name LANGUAGES C CXX)
```
Right now this works because the generator information is not used until the `project()` invocation - specifically the `set_languages()` part - and setting `CMAKE_MAKE_PROGRAM` will cause the generator initialization to skip looking for a binary in `PATH`.
Is this expected behavior? Is it something that I can keep relying on? Put another way, in the future, might CMake decide to set up the generator earlier, say, before the main `CMakeLists.txt` is parsed? AFAICT, this behavior is not documented anywhere right now. Should it be?
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [June 7, 2024, 4:10am UTC](https://discourse.cmake.org/t/manually-setting-cmake-make-program-before-calling-project/10967/2 "2024-06-07T04:10:46Z")
I wouldn’t say it is guaranteed to remain safe into the future, but it is unlikely to become unsafe. I would say that you shouldn’t put `FORCE` there though, it stops the developer from providing their own path to the build tool. FWIW, I wouldn’t try to set `CMAKE_MAKE_PROGRAM` directly in the project at all. It is meant to be something the user is responsible for if they are not putting the build tool on the PATH. If you’re using CMake presets, there may be an argument to set `CMAKE_MAKE_PROGRAM` there.
---
### Author:  [@Fabrice\_de\_Gans](https://discourse.cmake.org/u/Fabrice_de_Gans)
#### Post date: [June 7, 2024, 7:27pm UTC](https://discourse.cmake.org/t/manually-setting-cmake-make-program-before-calling-project/10967/3 "2024-06-07T19:27:35Z")
Thanks for getting back to me.
The idea here is to make the build more hermetic and reproducible by pinning the generator version dependency, hence overriding the environment information. I take it a better way to do so would be to install the prebuilt separately and provide it to CMake via `CMAKE_MAKE_PROGRAM`.
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [June 7, 2024, 10:35pm UTC](https://discourse.cmake.org/t/manually-setting-cmake-make-program-before-calling-project/10967/4 "2024-06-07T22:35:01Z")
> [@Fabrice\_de\_Gans](#):
>
> I take it a better way to do so would be to install the prebuilt separately and provide it to CMake via `CMAKE_MAKE_PROGRAM`.
Yes, that’s what I would recommend. The user should be in control of providing that `CMAKE_MAKE_PROGRAM` variable, but putting it in a CMake preset would satisfy that (users can always override a preset with a `-D` command-line option).