# Thoughts on using CPM.cmake as FetchContent Alternative

**URL:** <https://discourse.bemanproject.org/t/thoughts-on-using-cpm-cmake-as-fetchcontent-alternative/221>\
**Category:** Beman Project Development\
**Tags:** cmake, packaging\
**Created:** [September 24, 2024, 4:38pm UTC](https://discourse.bemanproject.org/t/thoughts-on-using-cpm-cmake-as-fetchcontent-alternative/221 "2024-09-24T16:38:29Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![paul](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/paul/32/105_2.png) [@paul](https://discourse.bemanproject.org/u/paul)\
**Post date:** [September 24, 2024, 4:38pm UTC](https://discourse.bemanproject.org/t/thoughts-on-using-cpm-cmake-as-fetchcontent-alternative/221/1 "2024-09-24T16:38:29Z")

</div>

It seems like for the short term, we are using `FetchContent` to get testing dependencies into Beman libraries. I personally think this is a fine solution for simple test dependencies but I wanted to throw [CPM.cmake](https://github.com/cpm-cmake/CPM.cmake) out there as it is something we use quite a bit and it works quite well for us in our use case at [Xstrahl](https://xstrahl.com).

One thing I like about it is that you can adapt it’s behavior to use only local packages with CMake flags.

A simple way to include it is found [here](https://github.com/cpm-cmake/CPM.cmake/wiki/Downloading-CPM.cmake-in-CMake). It would add another download for building with tests enabled, but this would only apply to devs working on a project. Consumers would not be affected by this.

---

<div class="post-metadata">

**Author:** ![mpusz](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/mpusz/32/109_2.png) [@mpusz](https://discourse.bemanproject.org/u/mpusz)\
**Post date:** [September 24, 2024, 6:12pm UTC](https://discourse.bemanproject.org/t/thoughts-on-using-cpm-cmake-as-fetchcontent-alternative/221/2 "2024-09-24T18:12:50Z")

</div>

Please note that [every CMake `add_subdirectory`-based solution does not scale](https://youtu.be/mrSwJBJ-0z8?si=cYIMzMqfgCsxQVAO&t=1930). This includes both `FetchContent` and `CPM`.

If we start using our libraries as dependencies on our other libraries (again, probably with FetchContent or CPM), we may have some problems because of that. The most severe typical issues are:

- CMake target duplicates that fail CMake builds,
- CTest tests of dependencies in our CTest runs,
- GTest version conflicts,
- long builds and runs (all dependencies will also fetch their testing frameworks and try to run them).

---

<div class="post-metadata">

**Author:** ![paul](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/paul/32/105_2.png) [@paul](https://discourse.bemanproject.org/u/paul)\
**Post date:** [September 24, 2024, 6:18pm UTC](https://discourse.bemanproject.org/t/thoughts-on-using-cpm-cmake-as-fetchcontent-alternative/221/3 "2024-09-24T18:18:01Z")

</div>

> [@mpusz](#):
>
> If we start using our libraries as dependencies on our other libraries (again, probably with FetchContent or CPM), we may have some problems because of that. The most severe typical issues are:
> 
> - CMake target duplicates that fail CMake builds,
> - CTest tests of dependencies in our CTest runs,
> - GTest version conflicts,
> - long builds and runs (all dependencies will also fetch their testing frameworks and try to run them).

I agree, this is not a way to handle large number of dependencies. But for simple things like GTest or `doctest` it works well enough and is quite simple.

If we plan on adding dependencies between different beman libraries, it would probably be better to set up a custom package index if using `vcpkg` or use Conan.

---

<div class="post-metadata">

**Author:** ![Sdowney](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/sdowney/32/73_2.png) [@Sdowney](https://discourse.bemanproject.org/u/Sdowney)\
**Post date:** [September 25, 2024, 1:24am UTC](https://discourse.bemanproject.org/t/thoughts-on-using-cpm-cmake-as-fetchcontent-alternative/221/4 "2024-09-25T01:24:10Z")

</div>

There are Cmake idioms for not building and running tests if you are not the top level project, so we should be able to avoid the repeated testing exponential problems.

It would be very infeasible if we were moving outside the standard library, but since most of it is not compiled into libraries we should also be able to avoid building more than we need for testing the components under test.

But, without some sort of package management system that generates consistent artifacts for a link context, we’re not going to scale much beyond the standard library.

---

<div class="post-metadata">

**Author:** ![Sdowney](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/sdowney/32/73_2.png) [@Sdowney](https://discourse.bemanproject.org/u/Sdowney)\
**Post date:** [September 25, 2024, 3:56pm UTC](https://discourse.bemanproject.org/t/thoughts-on-using-cpm-cmake-as-fetchcontent-alternative/221/5 "2024-09-25T15:56:09Z")

</div>

From Professional CMake 19th edition:

```auto
# CMake 3.21 or later is required for PROJECT_IS_TOP_LEVEL
option(MYPROJ_ENABLE_TESTING "..." ${PROJECT_IS_TOP_LEVEL})
if(MYPROJ_ENABLE_TESTING)
  add_subdirectory(tests)
endif()
if(PROJECT_IS_TOP_LEVEL)
  add_subdirectory(packaging)
else()
  # Users are unlikely to be interested in testing this
  # project, so don't show it in the basic options
  mark_as_advanced(MYPROJ_ENABLE_TESTING)
endif()

```

This is the recommended idiom for a project meant to be consumed as a cmake project by other cmake projects.

Note - packaging is mentioned here, but we may end up doing it all somewhat differently; the packaging subdir is if you’re using the CMake packaging tools.

---

<div class="post-metadata">

**Author:** ![dsankel](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/dsankel/32/5_2.png) [@dsankel](https://discourse.bemanproject.org/u/dsankel)\
**Post date:** [October 2, 2024, 7:55pm UTC](https://discourse.bemanproject.org/t/thoughts-on-using-cpm-cmake-as-fetchcontent-alternative/221/6 "2024-10-02T19:55:44Z")

</div>

> [@mpusz](#):
>
> Please note that [every CMake `add_subdirectory`-based solution does not scale](https://youtu.be/mrSwJBJ-0z8?si=cYIMzMqfgCsxQVAO&t=1930). This includes both `FetchContent` and `CPM`.

Thanks for the video link. That was interesting.

> [@](#):
>
> If we start using our libraries as dependencies on our other libraries (again, probably with FetchContent or CPM), we may have some problems because of that. The most severe typical issues are:
> 
> - CMake target duplicates that fail CMake builds,

My understanding is that this is mitigated by our naming convention which has all target names prefixed with `beman.<short_name>.`

> [@](#):
>
> - CTest tests of dependencies in our CTest runs,

I think this is mitigated with the technique @Sdowney mentioned above or passing `BUILD_TESTING=OFF` when invoking `FetchContent_Declare` which is what we do in beman.exemplar.

> [@](#):
>
> - GTest version conflicts,

I think this is mitigated by `FetchContent_Declare` since the first call takes precidence over all subsquent calls.

> [@](#):
>
> - long builds and runs (all dependencies will also fetch their testing frameworks and try to run them).

I think this is also mitigated by the `BUILD_TESTING=OFF``FetchContent_Declare` technique.

Can you think of any other issues that we need to think about @mpusz?

---

<div class="post-metadata">

**Author:** ![dsankel](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/dsankel/32/5_2.png) [@dsankel](https://discourse.bemanproject.org/u/dsankel)\
**Post date:** [October 2, 2024, 8:09pm UTC](https://discourse.bemanproject.org/t/thoughts-on-using-cpm-cmake-as-fetchcontent-alternative/221/7 "2024-10-02T20:09:00Z")

</div>

> [@paul](#):
>
> One thing I like about it is that you can adapt it’s behavior to use only local packages with CMake flags.

I assume you’re talking about [local package override](https://github.com/cpm-cmake/CPM.cmake?tab=readme-ov-file#local-package-override). Yeah, I can see that coming in really handy for large projects.

I wonder how you would do that with `FetchContent_Declare`. I guess you’d have to put a `FetchContent_Declare` call pointing to the local repository in the top-level `CMakeLists.txt` file of your project.

For reference, `CPMAddPackage` is used 3.6k times in GitHub and `FetchContent_Declare` is used 35.7k times.

---

<div class="post-metadata">

**Author:** ![paul](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/paul/32/105_2.png) [@paul](https://discourse.bemanproject.org/u/paul)\
**Post date:** [October 2, 2024, 8:38pm UTC](https://discourse.bemanproject.org/t/thoughts-on-using-cpm-cmake-as-fetchcontent-alternative/221/8 "2024-10-02T20:38:53Z")

</div>

I actually meant the [USE\_LOCAL\_PACKAGES](https://github.com/cpm-cmake/CPM.cmake#cpm_use_local_packages) flag. You can force CPM to work only with `find_package`.

CPM seems to create a cache of packages that are added to it and it can decide what to do for dependencies based on if the above environment flag is set or not. If it is it just delegates to `find_package` and otherwise it uses the regular `FetchContent` machinery.

---

<div class="post-metadata">

**Author:** ![bretbrownjr](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/bretbrownjr/32/43_2.png) [@bretbrownjr](https://discourse.bemanproject.org/u/bretbrownjr)\
**Post date:** [October 4, 2024, 10:14am UTC](https://discourse.bemanproject.org/t/thoughts-on-using-cpm-cmake-as-fetchcontent-alternative/221/9 "2024-10-04T10:14:20Z")

</div>

For the record, we started using FetchContent because we started tooling in a hackathon and it was trivial to bootstrap.

To me, this discussion thread is evidence that we’re ready to revisit the use of FetchContent and move to proper packaging. I believe effort sunk into developing styles and conventions to support recursive vendoring workflows are better spent getting Conan and/or vcpkg working for us.

I do think we should shoot for FetchContent friendly projects, but there’s a general portability problem when every project needs to detect whether it’s in some environment or another before it decides to perform this or that operation. That’s a pear-shaped approach to an ecosystem consistency problem. We would be expecting every project to be manually maintained to be consistent with every other project. And all projects to get individual updates as our expectations evolve.

---

<div class="post-metadata">

**Author:** ![dsankel](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/dsankel/32/5_2.png) [@dsankel](https://discourse.bemanproject.org/u/dsankel)\
**Post date:** [October 8, 2024, 8:40pm UTC](https://discourse.bemanproject.org/t/thoughts-on-using-cpm-cmake-as-fetchcontent-alternative/221/10 "2024-10-08T20:40:50Z")

</div>

> [@paul](#):
>
> I actually meant the [USE\_LOCAL\_PACKAGES](https://github.com/cpm-cmake/CPM.cmake#cpm_use_local_packages) flag. You can force CPM to work only with `find_package`.

It looks like `FetchContent_Declare()` has a [similar variable](https://cmake.org/cmake/help/latest/module/FetchContent.html#integrating-with-find-package), `FETCHCONTENT_TRY_FIND_PACKAGE_MODE`. I wonder if the CMake folks are porting the popular CPM features into fetch content directly.

---

<div class="post-metadata">

**Author:** ![bretbrownjr](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/bretbrownjr/32/43_2.png) [@bretbrownjr](https://discourse.bemanproject.org/u/bretbrownjr)\
**Post date:** [October 14, 2024, 2:09pm UTC](https://discourse.bemanproject.org/t/thoughts-on-using-cpm-cmake-as-fetchcontent-alternative/221/11 "2024-10-14T14:09:56Z")

</div>

Craig Scott has been mansterminding the convergence of find\_package and FetchContent.

I’m supportive, but at my day job, we need to push beyond `find_package` and into a more general interface for discovering transitive dependencies. We’ve been taking two approaches to facilitate that:

We’ve stopped using any [1] of `FetchContent` or `find_package` directly for dependency resolution. We have a more generic API called `RequiredTargets` that:

- Lets you declare in `CMakeLists.txt` that you need a dependency
- Lets a toolchain (or you if you really want) define how to resolve a named target into a concrete dependency [2].
- In one big pass at the end of configuration time, fulfills those requirements
- Anything tagets declared before `CMakeLists.txt` completes

One day, I’d like all of the above be useful and usable by everyone, including Beman libraries. Though it’s definitely a shift from existing CMake recommendations, including “modern CMake”.

[1] OK, we do use `find_package` in a few exotic cases, but it’s mostly for when the build system needs to enhance, override, or otherwise fill in very specific gaps that normal packaging mechanisms can’t support.

[2] Supported resolution policies include `pkg-config`, `find_package`, and (soon, hopefully) CPS files.

---

<div class="post-metadata">

**Author:** ![dsankel](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/dsankel/32/5_2.png) [@dsankel](https://discourse.bemanproject.org/u/dsankel)\
**Post date:** [October 15, 2024, 5:45pm UTC](https://discourse.bemanproject.org/t/thoughts-on-using-cpm-cmake-as-fetchcontent-alternative/221/12 "2024-10-15T17:45:48Z")

</div>

> [@bretbrownjr](#):
>
> at my day job, we need to push beyond `find_package` and into a more general interface for discovering transitive dependencies

I wonder what functionality you find FetchContent lacking. It seems to me like it also supports defining how to resolve named targets with a tool chain.

---

<div class="post-metadata">

**Author:** ![bretbrownjr](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/bretbrownjr/32/43_2.png) [@bretbrownjr](https://discourse.bemanproject.org/u/bretbrownjr)\
**Post date:** [October 28, 2024, 1:24pm UTC](https://discourse.bemanproject.org/t/thoughts-on-using-cpm-cmake-as-fetchcontent-alternative/221/13 "2024-10-28T13:24:00Z")

</div>

`FetchContent` and `find_package` provide a way to create a specifically IMPORTED target.

The problem with this is that my organization has a lot of workflows in which engineers need to edit several repos simultaneously in order to implement a feature or to troubleshoot problems that span multiple repos. For most dependencies, importing them is the right way to provide them. But when it comes to developing features that span repos or troubleshooting problems that involve multiple projects, it’s extremely helpful to be able to stitch together multiple repos into one build-edit-test workflow. Effectively, we can construct monorepos on the fly. When that’s interesting for development workflows.

Short of a feature like that, Beman will _have_ to invest in a package manager in order to support some version of the same development experience for use cases involving editing multiple Beman repos and/or dependencies of those projects. Even then, you’ll still need to drive build commands through more opaque packaging commands that might not know how to run a unit test or even attribute a build failure to a `cmake` command versus a `ninja` command.

Altogether, the status quo is workable. I’m just explaining why I see a better model on the horizon. But I still spend more cycles on packaging standards, so I suppose CMake dependency resolution semantics aren’t my biggest concern this week.

---

<div class="post-metadata">

**Author:** ![dsankel](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/dsankel/32/5_2.png) [@dsankel](https://discourse.bemanproject.org/u/dsankel)\
**Post date:** [October 30, 2024, 6:15pm UTC](https://discourse.bemanproject.org/t/thoughts-on-using-cpm-cmake-as-fetchcontent-alternative/221/14 "2024-10-30T18:15:24Z")

</div>

> [@bretbrownjr](#):
>
> when it comes to developing features that span repos or troubleshooting problems that involve multiple projects, it’s extremely helpful to be able to stitch together multiple repos into one build-edit-test workflow.

My understanding is that this kind of workflow is possible with `FetchContent`. Say you have an A → B → C dependency tree, both A and C’s code is checked out, and you’d like to make edits to C and A together as part of one build. There are two ways to do this:

## Option 1: Add a `FetchContent_Declare` using `SOURCE_DIR` in your top-level `CMakelists.txt`

Near the top of your top-level `CMakeLists.txt` for A, add a `FetchContent_Declare` for C pointing to your local checkout. This overrides all subsequent `FetchContent_Declare` calls for C (even in dependencies). For example

```auto
FetchContent_Declare(
  C
  SOURCE_DIR ${PROJECT_SOURCE_DIR}/../path/to/C/repo
)
FetchContent_MakeAvailable(C)

```

## Option 2: Set the `FETCHCONTENT_SOURCE_DIR_C` CMake variable to the path of your `C` checkout

Your CMake invocation would include `-DFETCHCONTENT_SOURCE_DIR_C=../path/to/C/repo`

---

<div class="post-metadata">

**Author:** ![bretbrownjr](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/bretbrownjr/32/43_2.png) [@bretbrownjr](https://discourse.bemanproject.org/u/bretbrownjr)\
**Post date:** [October 31, 2024, 2:51am UTC](https://discourse.bemanproject.org/t/thoughts-on-using-cpm-cmake-as-fetchcontent-alternative/221/15 "2024-10-31T02:51:44Z")

</div>

Except in the workflow I propose, you need no temporary edits to cloned `CMakeLists.txt`. You just add a top level `CMakeLists.txt` above all cloned repos and as many `add_subdirectory` calls as you need. Generally, we do this as an automated work area setup step, though it’s possible to write a `CMakeLists.txt` that automatically finds constituent projects given some modest layout and project structure assumptions.

---

<div class="post-metadata">

**Author:** ![dsankel](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/dsankel/32/5_2.png) [@dsankel](https://discourse.bemanproject.org/u/dsankel)\
**Post date:** [November 1, 2024, 2:50pm UTC](https://discourse.bemanproject.org/t/thoughts-on-using-cpm-cmake-as-fetchcontent-alternative/221/16 "2024-11-01T14:50:27Z")

</div>

> [@bretbrownjr](#):
>
> Except in the workflow I propose, you need no temporary edits to cloned `CMakeLists.txt`.

Option 2 above doesn’t involve editing any `CMakeLists.txt` files. Am I missing something?

---

<div class="post-metadata">

**Author:** ![bretbrownjr](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/bretbrownjr/32/43_2.png) [@bretbrownjr](https://discourse.bemanproject.org/u/bretbrownjr)\
**Post date:** [November 1, 2024, 6:15pm UTC](https://discourse.bemanproject.org/t/thoughts-on-using-cpm-cmake-as-fetchcontent-alternative/221/17 "2024-11-01T18:15:52Z")

</div>

I guess you could still make a new CMakeLists.txt and have it set FetchContent for everything you want to pull in? I don’t know why I would prefer that to add\_subdirectory calls I guess.

To be clear, all this is a little far afield given current Beman practices. I’m OK with whatever find\_package or FetchContent hacks we want to use for now. In particular we would at least want an acceptable RequiredTargets package to use that isn’t available now.

I’m just pointing out there is a way forward eventually that involves declaring dependencies instead of using imperative operations like “fetch”.

---

<div class="post-metadata">

**Author:** ![ClausKlein](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/clausklein/32/136_2.png) [@ClausKlein](https://discourse.bemanproject.org/u/ClausKlein)\
**Post date:** [November 20, 2024, 6:57am UTC](https://discourse.bemanproject.org/t/thoughts-on-using-cpm-cmake-as-fetchcontent-alternative/221/18 "2024-11-20T06:57:59Z")

</div>

I have been worked with `CPM.cmake` in many projects.

### The only problem I found is the interface of [CPMAddPackage()](https://github.com/cpm-cmake/CPM.cmake?tab=readme-ov-file#usage).

It is very inflexible and makes it difficult to use new options added to the underlaying `FetchContent` interface!  
Parameter Quoting is also strange.

### But I like the centralised cache and the other [options](https://github.com/cpm-cmake/CPM.cmake?tab=readme-ov-file#options)

These prevents many duplicates repros created with `FetchContent`:

```bash
bash-5.2$ find .build -type d -name googletest-src
.build/gcc-14/_deps/googletest-src
.build/system/_deps/googletest-src
.build/system/src/beman/optional26/tests/find-package-test/_deps/googletest-src
.build/clang-19/_deps/googletest-src
.build/clang-19/src/beman/optional26/tests/find-package-test/_deps/googletest-src
bash-5.2$ 

```

in contrast to:

```bash
bash-5.2$ ls -lrtd ~/.cache/CPM/[bgf]*
drwxr-xr-x 3 clausklein staff 96 Feb 11 2023 /Users/clausklein/.cache/CPM/b
drwxr-xr-x 3 clausklein staff 96 Feb 18 2023 /Users/clausklein/.cache/CPM/boost-fetch
drwxr-xr-x 23 clausklein staff 736 Feb 18 2023 /Users/clausklein/.cache/CPM/boost_1_79_0
drwxr-xr-x 26 clausklein staff 832 Feb 20 2023 /Users/clausklein/.cache/CPM/boost_1_80_0
drwxr-xr-x 4 clausklein staff 128 Mar 28 2023 /Users/clausklein/.cache/CPM/glm
drwxr-xr-x 4 clausklein staff 128 Mar 28 2023 /Users/clausklein/.cache/CPM/glew
drwxr-xr-x 5 clausklein staff 160 Aug 29 2023 /Users/clausklein/.cache/CPM/fmtlib
drwxr-xr-x 9 clausklein staff 288 Dec 7 2023 /Users/clausklein/.cache/CPM/format.cmake
drwxr-xr-x 6 clausklein staff 192 Dec 8 2023 /Users/clausklein/.cache/CPM/benchmark
drwxr-xr-x 4 clausklein staff 128 Dec 11 2023 /Users/clausklein/.cache/CPM/fakeit
drwxr-xr-x 11 clausklein staff 352 Dec 11 2023 /Users/clausklein/.cache/CPM/googletest
drwxr-xr-x 5 clausklein staff 160 Dec 11 2023 /Users/clausklein/.cache/CPM/fibonacci
drwxr-xr-x 12 clausklein staff 384 Dec 28 2023 /Users/clausklein/.cache/CPM/boost-cmake
drwxr-xr-x 4 clausklein staff 128 Feb 24 2024 /Users/clausklein/.cache/CPM/gtest
drwxr-xr-x 10 clausklein staff 320 Mar 19 2024 /Users/clausklein/.cache/CPM/boost
drwxr-xr-x 7 clausklein staff 224 Mar 20 2024 /Users/clausklein/.cache/CPM/ftxui
drwxr-xr-x 25 clausklein staff 800 Apr 29 2024 /Users/clausklein/.cache/CPM/boost_1_81_0
drwxr-xr-x 22 clausklein staff 704 Jun 12 03:22 /Users/clausklein/.cache/CPM/boost_1_84_0
drwxr-xr-x 22 clausklein staff 704 Sep 14 13:44 /Users/clausklein/.cache/CPM/fmt
bash-5.2$ 

```

---

<div class="post-metadata">

**Author:** ![paul](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/paul/32/105_2.png) [@paul](https://discourse.bemanproject.org/u/paul)\
**Post date:** [November 20, 2024, 12:46pm UTC](https://discourse.bemanproject.org/t/thoughts-on-using-cpm-cmake-as-fetchcontent-alternative/221/19 "2024-11-20T12:46:14Z")

</div>

> [@ClausKlein](#):
>
> I have been worked with `CPM.cmake` in many projects.
> 
> ### The only problem I found is the interface of [CPMAddPackage()](https://github.com/cpm-cmake/CPM.cmake?tab=readme-ov-file#usage).
> 
> It is very inflexible and makes it difficult to use new options added to the underlaying `FetchContent` interface!  
> Parameter Quoting is also strange.

Hi Claus,

Could you elaborate more on the problems you have found with `CPMAddPackage()`? We have used it extensively but I don’t think we’ve run into the limitations you allude to.

---

<div class="post-metadata">

**Author:** ![ClausKlein](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.bemanproject.org/clausklein/32/136_2.png) [@ClausKlein](https://discourse.bemanproject.org/u/ClausKlein)\
**Post date:** [November 20, 2024, 4:21pm UTC](https://discourse.bemanproject.org/t/thoughts-on-using-cpm-cmake-as-fetchcontent-alternative/221/20 "2024-11-20T16:21:23Z")

</div>

see [Pull requests · cpm-cmake/CPM.cmake · GitHub](https://github.com/cpm-cmake/CPM.cmake/pulls?q=is%3Apr+is%3Aclosed+author%3AClausKlein)

and [Preserving forwarding of empty string arguments by CraigHutchinson · Pull Request #461 · cpm-cmake/CPM.cmake · GitHub](https://github.com/cpm-cmake/CPM.cmake/pull/461)

Too there are general limitations (`CPM` and `FetchContent`) with complex packages like `boost`:

> **[Issues · cpm-cmake/CPM.cmake](https://github.com/cpm-cmake/CPM.cmake/issues?q=boost%2Bis%3Aopen)**
>
> 📦 CMake's missing package manager. A small CMake script for setup-free, cross-platform, reproducible dependency management. - Issues · cpm-cmake/CPM.cmake

> **[Why you should NOT use Boost git repo with CPM.cmake · cpm-cmake/CPM.cmake ·...](https://github.com/cpm-cmake/CPM.cmake/discussions/448)**
>
> the clone of the git repo takes to long time! and the boost CMake files are not really designed as modern CMake project! there is no central include directory! the boost CMake system is designed fo...

[Next page](https://discourse.bemanproject.org/t/thoughts-on-using-cpm-cmake-as-fetchcontent-alternative/221.md?page=2)