# FetchContent / CMAKE\_MAKE\_PROGRAM issue

**URL:** https://discourse.cmake.org/t/fetchcontent-cmake-make-program-issue/2522
**Category:** Usage
**Created:** [January 12, 2021, 5:48pm UTC](https://discourse.cmake.org/t/fetchcontent-cmake-make-program-issue/2522 "2021-01-12T17:48:21Z")
**Posts on this page:** 1
**Showing post:** 9

<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: [February 21, 2023, 10:10pm UTC](https://discourse.cmake.org/t/fetchcontent-cmake-make-program-issue/2522/9 "2023-02-21T22:10:56Z")

</div>

Not trying to resurrect an old thread, but leaving the below comment after ending up here while following links of a [recent discussion](https://discourse.cmake.org/t/built-in-package-manager-for-cmake-modules/7513).

> [@craig.scott](#):
>
> `FetchContent` needs whatever `CMAKE_MAKE_PROGRAM` points at to exist, since it uses that tool to do the content population.

There was [work I did for FetchContent](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5749) which avoided using a sub-build, but I had to [revert it](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5898) after it broke some existing behavior. I still harbour a desire to bring that change back in a form that avoids the previous problems. The performance gains on Windows especially make that highly desirable. As a nice side benefit, it would remove the above-mentioned problem and allow the original pattern discussed in this post to work (download the Ninja build tool via FetchContent before the first `project()` call).

I don’t know if or when I’ll get a chance to revisit that work for FetchContent, but it is still very much on my radar.

---

_[View the full topic](https://discourse.cmake.org/t/fetchcontent-cmake-make-program-issue/2522)._