fix(config): don't inject official global xim index into project scope (0.0.87)#205
Merged
Merged
Conversation
Project-local mode (a project with a custom `[indices]`, e.g. a local path index) force-added the official `xim` index into the project's `.xlings.json` `index_repos` (ensure_project_index_dir), intending to make `xim:*` deps resolvable in project mode. But xlings scopes by which group a repo lands in: packages from project `index_repos` are `PackageScope::Project`. So every `xim` GLOBAL tool (cmake/glibc/gcc/make/binutils/…) resolved project-scoped and installed into the project store instead of the shared registry. That broke ELF loader resolution for build-dep tools — a build-dep `xim:cmake`'s interpreter was patched to an unmaterialized project-store glibc → `cannot execute`. Any compat package running a glibc-dynamic build-dep tool in install() (e.g. a source-built CMake OpenCV) failed under `mcpp test`, universally (fresh MCPP_HOME too). global IS the default: `xim` (and its dynamically-discovered sub-indexes) are xlings global-default indices. `xim:*` resolves at global scope via the global index_repos + the registry-local xim clone, and stays visible to the project via additive. Only user-declared local custom indices are project-scoped. Remove the xim injection and the project-data-dir xim exposure; not a hardcoded allowlist — just don't inject an index the user didn't declare. Verified: opencv workspace member closes (cmake now installs to the global registry, project store holds only the local package); mcpp self-test 30/30; mcpp-index full workspace green. Design + analysis: .agents/docs/2026-07-09-project-index-scope-global-infra-fix.md Bumps 0.0.86 → 0.0.87. Claude-Session: https://claude.ai/code/session_01Y3KE7MAE8yV7BG35eXy7FV
…matches fix) The fake-xlings in 52_local_path_namespaced_index.sh asserted the OLD behavior (project .xlings.json must contain the official xim index). Flip it: xim is a global-default index and must NOT be injected project-scoped. Verified: e2e 52 OK. Claude-Session: https://claude.ai/code/session_01Y3KE7MAE8yV7BG35eXy7FV
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Project-local mode (a project with a custom
[indices], e.g. a local path index) force-added the officialximindex into the project's.xlings.jsonindex_repos(ensure_project_index_dir,config.cppm). But xlings scopes by which group a repo lands in — packages from projectindex_reposarePackageScope::Project. So everyximglobal tool (cmake/glibc/gcc/make/binutils) resolved project-scoped and installed into the project store instead of the shared registry.That broke ELF loader resolution for build-dep tools: a build-dep
xim:cmake's interpreter got patched to an unmaterialized project-store glibc →cannot execute: required file not found. Any compat package running a glibc-dynamic build-dep tool ininstall()(e.g. a source-built CMake OpenCV) failed undermcpp test, universally (freshMCPP_HOMEtoo — mcpp's toolchain bootstrap records glibc globally, which then shadowed the project store).Fix
global IS the default.
xim(and its dynamically-discovered sub-indexes) are xlings global-default indices;xim:*resolves at global scope via the globalindex_repos+ the registry-localximclone, and stays visible to the project via additive. Only user-declared local custom indices are project-scoped.ximinjection into the projectcustomRepos.ximcopy/exposure (dead once xim isn't a project repo).Verification
cmakeinstalls to the global registry, project store holds only the local package;test result ok.Config.ProjectIndexDirDoesNotInjectOfficialXimIndexto assert the correct behavior).Bumps 0.0.86 → 0.0.87.
Design + full root-cause analysis:
.agents/docs/2026-07-09-project-index-scope-global-infra-fix.mdhttps://claude.ai/code/session_01Y3KE7MAE8yV7BG35eXy7FV