Skip to content

Don't re-include an already-resolved dependency - #86

Merged
ryanmrichard merged 2 commits into
masterfrom
fix_repeat_dependency_resolution
Sep 11, 2026
Merged

ryanmrichard merged 2 commits into
masterfrom
fix_repeat_dependency_resolution

Conversation

@ryanmrichard

Copy link
Copy Markdown
Member

Summary

Fixes the No content details recorded for utilities configure error currently breaking every test_cmake_build leg across the ecosystem (SCF PR #73, SCF nightly, etc.).

get_dependencies() sets _gd_uses_fc TRUE per iteration and relies on nwx_ecosystem_dependency() to clear it. But every dependencies/*.cmake carries an include_guard(), and FetchContent_MakeAvailable() calls add_subdirectory() from inside get_dependencies()'s own function scope — so a fetched sibling's nested get_dependencies() call inherits those guard variables. The include() becomes a silent no-op, _gd_uses_fc keeps its TRUE default, and the name reaches FetchContent_MakeAvailable() having never been declared.

This was harmless while every dependency resolved from git master: the first include() declared it, so the repeat found its details and did nothing. Resolving from an installed wheel declares nothing, so it turned fatal as soon as NWChemEx/.github@aa6a0fa ("move pip install up") started pip-installing the ecosystem before configure — SCF's integration-testing build resolves utilities from its wheel, then hits it again via TensorWrapper's own get_dependencies() call.

Note this also means nwx_ecosystem_dependency()'s branch 2 ("already resolved") was unreachable in the nested case — the guard fired first.

Test plan

Reduced the CI failure to a local reproduction (installed ecosystem wheels in a venv; a local-source-dir sibling whose CMakeLists.txt makes the nested call), which fails on master with the identical error and call stack:

CMake Error at .../FetchContent.cmake:1263 (message):
  No content details recorded for utilities
Call Stack (most recent call first):
  .../get_dependencies.cmake:77 (FetchContent_MakeAvailable)
  fakewtf/CMakeLists.txt:6 (get_dependencies)

🤖 Generated with Claude Code

ryanmrichard and others added 2 commits September 11, 2026 13:07
get_dependencies() set _gd_uses_fc TRUE per iteration and relied on
nwx_ecosystem_dependency() to clear it. But every dependencies/*.cmake
carries an include_guard(), and FetchContent_MakeAvailable() runs
add_subdirectory() from inside get_dependencies()'s own function scope,
so a fetched sibling's nested get_dependencies() call inherits those
guard variables: include() becomes a silent no-op, _gd_uses_fc keeps
its TRUE default, and the name reaches FetchContent_MakeAvailable()
having never been declared ("No content details recorded for <name>").

Harmless while every dependency came from git master -- the first
include() declared it, so the repeat found its details. Resolving from
an installed wheel declares nothing, so it became fatal as soon as CI
started pip-installing the ecosystem before configure: SCF's
integration-testing build resolves utilities from its wheel, then hits
it again via tensorwrapper's own get_dependencies() call.

Short-circuit such dependencies before the include() instead, reusing
the NWX_DEP_TARGET_<name> mapping already recorded for every resolved
dependency.
@ryanmrichard
ryanmrichard merged commit 33267e6 into master Sep 11, 2026
8 checks passed
@ryanmrichard
ryanmrichard deleted the fix_repeat_dependency_resolution branch September 11, 2026 18:20
@github-actions

Copy link
Copy Markdown

🚀 [bumpr] Bumped!
New version:v0.2.1
Changes:v0.2.0...v0.2.1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant