# Out of source builds and caching external assets

**URL:** https://discourse.cmake.org/t/out-of-source-builds-and-caching-external-assets/10533
**Category:** Development
**Created:** [March 29, 2024, 5:26pm UTC](https://discourse.cmake.org/t/out-of-source-builds-and-caching-external-assets/10533 "2024-03-29T17:26:23Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![jjYBdx4IL](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/j/b487fb/32.png) [@jjYBdx4IL](https://discourse.cmake.org/u/jjYBdx4IL)
#### Post date: [March 29, 2024, 5:26pm UTC](https://discourse.cmake.org/t/out-of-source-builds-and-caching-external-assets/10533/1 "2024-03-29T17:26:23Z")

</div>

Proposal:

ExternalProject and FetchContent modules re-download external archives instead of caching them out of source and out of build. That is sub-optimal for two reasons:

a) I might lose connectivity. Or I might work offline. Or the download server goes offline or dies terminally. Tough luck if I accidentally wipe the build.  
b) When working on build issues, regular wipes of the build cannot be avoided, hence creating quite an unnecessary load on external infrastructure like github.

Second, out of source builds could be done by default whenever there is a corresponding env variable set. No more defining the build directory. Those two issues could be combined via one env var that defines the out of source build root dir, ie. $CMAKE\_OOS\_DIR. Downloaded assets could be stored by default under $CMAKE\_OSS\_DIR/.cache and builds could go to $CMAKE\_OSS\_DIR/$PROJECTNAME (or similar).

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: [April 11, 2024, 4:09pm UTC](https://discourse.cmake.org/t/out-of-source-builds-and-caching-external-assets/10533/2 "2024-04-11T16:09:16Z")

</div>

In my `ExternalProject` builds, I have them directed to store to `${CMAKE_BINARY_DIR}/downloads`. On my machine, I symlink this to a common store between a variety of superbuilds. There’s been discussion to have a user-wide cache for `ExternalProject` sources (which I assume will help `FetchContent` as well), but it’s not a simple thing (especially for VCS sources).

See this discussion and links from it: [ExternalProject\_Add cache for git repositories](https://discourse.cmake.org/t/externalproject-add-cache-for-git-repositories/4218)

---

<div class="post-metadata">

### Author: ![jjYBdx4IL](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/j/b487fb/32.png) [@jjYBdx4IL](https://discourse.cmake.org/u/jjYBdx4IL)
#### Post date: [April 11, 2024, 6:31pm UTC](https://discourse.cmake.org/t/out-of-source-builds-and-caching-external-assets/10533/3 "2024-04-11T18:31:30Z")

</div>

Yes, I don’t care about VCS sources. Let them be how they are for now. This proposal makes mostly sense for archives. And you can download individual revisions from github via archive, too. Supporting caching of archives is better than nothing.

I already wrote a workaround: [GitHub - jjYBdx4IL/dlcache: A simple file-backed download cache](https://github.com/jjYBdx4IL/dlcache)

It returns a value pointing to a local copy of the archive, which one can feed to ExternalProject etc.