FetchContent population reuse semantics when re-entering a superbuild from a different directory scope

Question

ContextFetchContent is documented to populate external sources once per build tree, caching the result under the build directory and reusing it on subsequent configures unless the declared URL, URL_HASH, or content changes. This contract works predictably for a single top-level configure run.AmbiguityWhen a superbuild re-enters its own CMake logic from a different directory scope — for example, a nested add_subdirectory that re-invokes FetchContent_MakeAvailable for the same declared dependency — the cache invalidation rules become unclear. The populated source directory exists, but the module may re-evaluate the declare step in a new scope, potentially triggering a second population or skipping it silently depending on CMake version and policy settings (e.g., CMP0145). Multi-config generators and partial build-tree cleans add further variance.GoalDetermine whether FetchContent guarantees idempotent reuse across re-configure entry points in different directory scopes, or whether the population step can run again and under what exact conditions.Does the cache key incorporate the calling directory scope, or is it purely based on the declared content identifiers?Which CMake policies or version thresholds change the reuse behavior for nested superbuild entry points?Is there a documented way to force or suppress re-population without altering URL_HASH?

Tasadduq Burney · Answer

Answer When a superbuild re‑enters its own CMake logic from a different directory scope—e.g., a nested add_subdirectory that calls FetchContent_MakeAvailable again—the source and binary directories that were populated the first time are reused. CMake stores the state of every FetchContent_Declare in global properties keyed only by the lower‑cased name. The first declaration for a given name wins; subsequent declares from any scope are ignored unless a policy or variable forces a different outcome. Key facts The cache key is independent of the calling directory scope. It consists of the declared name and the URL, URL_HASH, GIT_TAG, etc., stored in global properties. Policies that influence this behaviour: CMP0145 (since CMake 3.12) dictates whether a second FetchContent_Declare for the same name is ignored. CMP0168 and CMP0169 (CMake 3.30+) deprecate direct FetchContent_Populate(name) and promote MakeAvailable as the sole public API. Re‑population on re‑configure is governed by: FETCHCONTENT_UPDATES_DISCONNECTED – skip the update step for VCS content. FETCHCONTENT_FULLY_DISCONNECTED – assume the source is already populated and skip any download or update. Per‑dependency UPDATE_DISCONNECTED – same effect but scoped to a single dependency. Partial clean‑ups that delete the _deps/-subbuild directory or the stamp files will cause the next configure to re‑run the population step, even though the source cache still exists. Practical verification steps Run a normal configure: cmake -S . -B build Inspect the global property that records the source directory: get_property(_src GLOBAL PROPERTY _FetchContent__SOURCE_DIR) message("Source dir: ${_src}") Add a nested add_subdirectory that also calls FetchContent_MakeAvailable(). Re‑run the configure from the top level. The log should show that the subdirectory is added but the download step is skipped. To force a re‑population, set FETCHCONTENT_FULLY_DISCONNECTED=ON before the second configure and observe that no download occurs. What to check if you observe unexpected behaviour What CMake version are you using? Policies like CMP0145, CMP0168, CMP0169 only exist from certain releases. Did a partial clean remove _deps/-subbuild or the stamp file? Are you using a multi‑config generator? That does not change the reuse key, but it can lead to stale cache entries if the same build tree is reused with different configuration options.

FetchContent population reuse semantics when re-entering a superbuild from a different directory scope

Context

Ambiguity

Goal

1 answer

Answer

Key facts

Practical verification steps

What to check if you observe unexpected behaviour

Your perspective belongs here.

0 question comments