You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
`xlings` now builds through `mcpp` and uses a local project index:
6
+
7
+
```toml
8
+
[indices]
9
+
xlings = { path = "mcpp" }
10
+
```
11
+
12
+
During a first build, `mcpp build` currently prints `Fetching custom index repos (first use)` followed by `xlings update` output, then emits warnings such as:
The build itself can still succeed, but the dependency BMI cache is not populated for affected packages.
20
+
21
+
## Root Cause
22
+
23
+
There are two related build-tool issues.
24
+
25
+
1. Project custom-index bootstrap is too broad.
26
+
27
+
`mcpp` seeds `.mcpp/.xlings.json` for non-builtin `[indices]` and treats the project index data as uninitialized when no `xim-indexrepos.json` or cloned `pkgs/` directory exists. It then runs `xlings update`, which prints all configured xlings index update output. For a local path index, the local `pkgs/` tree already exists and can be read directly, so the update path is mostly noise and can create extra first-build work.
28
+
29
+
2. BMI cache records object basenames instead of object paths relative to `obj/`.
30
+
31
+
The build plan correctly writes objects under collision-avoiding subdirectories, for example:
32
+
33
+
```text
34
+
obj/mcpplibs_tinyhttps_src/tinyhttps.m.o
35
+
obj/xlings_libarchive_libarchive/xxhash.o
36
+
obj/xlings_zlib_zlib-1.3.2/compress.o
37
+
```
38
+
39
+
The cache populate list currently stores only `cu.object.filename()`, so it later searches for:
40
+
41
+
```text
42
+
obj/tinyhttps.m.o
43
+
obj/xxhash.o
44
+
obj/compress.o
45
+
```
46
+
47
+
Those files do not exist, so `populate_from()` returns `expected build output missing`.
48
+
49
+
There is also a cache-key correctness gap: all dependency cache entries currently use the default index name. Custom-index dependencies should carry their real namespace/index identity so cache entries from different indices do not collide.
50
+
51
+
## Fix Plan
52
+
53
+
1. Add regression coverage first.
54
+
- Add an e2e regression that builds a local-path custom-index dependency with duplicate object basenames.
55
+
- Assert that local-path indices do not trigger first-use `xlings update` noise.
56
+
- Assert that the cache manifest is written under the custom index name and preserves nested object paths.
57
+
- Assert that a second cold build reuses the dependency BMI cache.
58
+
59
+
2. Fix artifact path recording.
60
+
- When collecting dependency artifacts in `src/cli.cppm`, store object paths relative to `ctx.outputDir / "obj"` instead of only the object filename.
61
+
- Keep BMI filenames as basenames because compiler BMI output is intentionally flat in the active BMI directory.
62
+
63
+
3. Fix dependency cache identity.
64
+
- Use the dependency namespace or custom index name in `CacheKey::indexName` instead of always using the global default index.
65
+
- Preserve builtin/default behavior for existing `mcpplibs` packages.
66
+
67
+
4. Reduce local custom-index update noise.
68
+
- Treat local `{ path = ... }` indices as initialized when the source path has a `pkgs/` directory.
69
+
- Keep remote custom indices on the existing project `xlings update` path.
70
+
71
+
5. Verify.
72
+
- Run targeted BMI cache unit tests.
73
+
- Run the broader unit suite or project test command available in the repository.
74
+
- Run a local `mcpp build` scenario when feasible to ensure the original warning no longer appears.
75
+
76
+
## Dynamic Notes
77
+
78
+
- If tests reveal that `CacheKey::indexName` is used as a namespace rather than a repository identity, prefer the package namespace as the cache partition and document the remaining repository-revision hardening as follow-up.
79
+
- If local path indices still need xlings project metadata for install operations, skip only the update call, not `.mcpp/.xlings.json` seeding.
80
+
- Implemented regression as `tests/e2e/49_bmi_cache_nested_custom_index.sh` because the defect is in CLI dependency resolution plus build-plan artifact collection, not only the lower-level cache copy functions.
81
+
- Local verification: `mcpp build` succeeded, then `MCPP=target/x86_64-linux-gnu/4d24c8b57fdbbbb4/bin/mcpp bash tests/e2e/49_bmi_cache_nested_custom_index.sh` returned `OK`.
82
+
-`mcpp test -- --gtest_filter=BmiCache.*` initially exposed an unrelated local environment issue: `~/.mcpp/registry/data/xpkgs/xim-x-binutils/2.42` only had `.xpkg.lua` and no `bin/as`. Re-running with a temporary `MCPP_HOME` pointed at the complete installed mcpp registry passed: 15 test binaries ok, 0 failed.
83
+
- Remote custom-index first-use sync keeps the mcpp-level `Fetching custom index repos (first use)` status, but calls `update_index(..., quiet=true)` so `mcpp build` does not expose xlings update output. A non-zero update exits with a concise mcpp-level error.
0 commit comments