# Unified Fetched Content with FETCHCONTENT\_BASE\_DIR
**URL:** https://discourse.cmake.org/t/unified-fetched-content-with-fetchcontent-base-dir/10321
**Category:** Development
**Created:** [March 7, 2024, 8:49pm UTC](https://discourse.cmake.org/t/unified-fetched-content-with-fetchcontent-base-dir/10321 "2024-03-07T20:49:03Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@anthonya](https://discourse.cmake.org/u/anthonya)
#### Post date: [March 7, 2024, 8:49pm UTC](https://discourse.cmake.org/t/unified-fetched-content-with-fetchcontent-base-dir/10321/1 "2024-03-07T20:49:03Z")
Over in discussion [FetchContent base directory and CMakePresets](https://discourse.cmake.org/t/fetchcontent-base-directory-and-cmakepresets/6722),
@craig.scott said the following:
> [@FetchContent base directory and CMakePresets](https://discourse.cmake.org/t/fetchcontent-base-directory-and-cmakepresets/6722/2):
>
> Do not share a `FETCHCONTENT_BASE_DIR` between different builds. That shares more than just the downloaded sources, it also shares all the bookkeeping files used internally. Those do not expect to have the source directory changing between runs. In particular, the sub-build set up to do the download won’t tolerate the architecture changing, which is what you’re seeing because the sub-build uses the same generator as the main build.
>
> While I understand the desire to want to avoid duplicating the downloaded content when you have two or more builds that need the same thing, that isn’t something that FetchContent supports very well right now.
I wanted to revisit this discussion. Is it possible to make this idea something that FetchContent _does_ support well?
For context, this problem also came up in the JS community and was solved with [https://pnpm.io/](https://pnpm.io/). On the motivation and FAQ pages, [Motivation | pnpm](https://pnpm.io/motivation) and [Frequently Asked Questions | pnpm](https://pnpm.io/faq), they walk through their idea of using a global cached directory for dependencies which then hard links into each individual project’s build folder. I personally tried it and it was fantastic.
This problem currently hit me in the CMake world. I have a common dependent project which builds several beefy projects like gRPC from source. All 4 of my projects that use this dependency have to have their own downloaded copy of it, and their own libs built out. Making `FETCHCONTENT_BASE_DIR` work with a global cache would make this process much more time and space efficient.
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [March 7, 2024, 9:08pm UTC](https://discourse.cmake.org/t/unified-fetched-content-with-fetchcontent-base-dir/10321/2 "2024-03-07T21:08:17Z")
> [@anthonya](#):
>
> I wanted to revisit this discussion. Is it possible to make this idea something that FetchContent _does_ support well?
It may be possible. I think about it very often. It’s a pretty complex feature though, as there’s a number of different download methods, you have to tolerate projects that don’t behave like good CMake citizens (e.g. some write to their source directory, which is why hard-linking to a cached version isn’t appropriate for CMake projects), and I’m very wary of scope creep in CMake expanding this into an area better served by its own dedicated package manager.
I wouldn’t focus on `FETCHCONTENT_BASE_DIR` as a solution. That’s not a path to happiness. I actually wish I’d never exposed that as part of the FetchContent API. It gets too much attention for a use case it was not meant to support, and it encourages unsafe practices such as trying to share the base dir between builds.
---
### Author:  [@anthonya](https://discourse.cmake.org/u/anthonya)
#### Post date: [March 7, 2024, 9:42pm UTC](https://discourse.cmake.org/t/unified-fetched-content-with-fetchcontent-base-dir/10321/3 "2024-03-07T21:42:06Z")
Sounds fair, thanks for the quick response Craig. You mentioned that this may be a better fit for a dedicated package manager, but I purposely moved away from them in favor of FetchContent.
I tried vcpkg, but the ecosystem just isn’t built for scale. It relies on community contributions to keep ports working, and I encountered several scenarios where I had to opt-out in order to move forward on my builds. I made contributions to CMake builds across several OSS projects, and that turned out to be a much more efficient and scaleable process. It allowed me to reduce the hacks needed my side in order to have clean FetchContent code.
---
### Author:  [@anthonya](https://discourse.cmake.org/u/anthonya)
#### Post date: [March 11, 2024, 6:08pm UTC](https://discourse.cmake.org/t/unified-fetched-content-with-fetchcontent-base-dir/10321/4 "2024-03-11T18:08:29Z")
I was thinking about this over the weekend. If one were to add support for it in CMake, what steps would it take to implement it? Perhaps I and/or others could all chip at it until we get there.
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [March 13, 2024, 11:53am UTC](https://discourse.cmake.org/t/unified-fetched-content-with-fetchcontent-base-dir/10321/5 "2024-03-13T11:53:42Z")
It will take me some time to compile a list of things to consider and the explanations to go with them. I probably need to do that anyway, but I have to admit, it’s not high on my priority list at the moment.
---
### Author:  [@eduardz1](https://discourse.cmake.org/u/eduardz1)
#### Post date: [September 30, 2025, 12:19pm UTC](https://discourse.cmake.org/t/unified-fetched-content-with-fetchcontent-base-dir/10321/6 "2025-09-30T12:19:56Z")
Hello, has there been any progress on that front? Currently we rely a lot on the caching feature provided by CPM ( [CPM.cmake/README.md at master · cpm-cmake/CPM.cmake · GitHub](https://github.com/cpm-cmake/CPM.cmake/blob/master/README.md#cpm_source_cache) ) to allow for complete offline configuration and avoid re-downloading the dependencies every time in the CI. In my opinion, they have a very good and simple implementation for caching based on hashes, so I think it could be taken as reference for a direct implementation in CMake. It would be nice not having to depend on an external project. Thank you!
---
### Author:  [@benthevining](https://discourse.cmake.org/u/benthevining)
#### Post date: [September 30, 2025, 8:44pm UTC](https://discourse.cmake.org/t/unified-fetched-content-with-fetchcontent-base-dir/10321/7 "2025-09-30T20:44:35Z")
+1 to this. I personally would love if native FetchContent supported this caching feature, this would completely eliminate the need for CPM.