test(e2e): read the cache root from mcpp, not from a bash re-derivation - #318
Merged
Conversation
170 asserted the staging source lived under ${MCPP_HOME:-$HOME/.mcpp}/build-cache/v1.
That re-derivation is wrong for a SELF-CONTAINED install, where the unpacked tree
itself is the home — the shape of every release tarball and every
`xlings install mcpp`. Running the suite against the released 2026.7.30.2 binary
therefore failed the test while the binary was correct:
FAIL: std BMI cache is '<tarball>/build-cache/v1/std/...',
expected under '/home/speak/.mcpp/build-cache/v1/std'
CI never saw it because the binary under test lives at target/<triple>/<fp>/bin/mcpp,
which mcpp.home::root() deliberately disqualifies from self-contained detection.
The root now comes from `mcpp cache dir`, which exists precisely so "where is the
cache" has one answer. Verified passing against both shapes: the released tarball
binary and a dev build.
…the cache
Fallout from making the global cache work, and one of the two is a negative
assertion my change silently weakened.
163 asserted `Compiling acme.widget`. What it tests is that the descriptor was
found BY IDENTITY and the package joined the build; whether its objects were
compiled here or served from the cache belongs to a different subsystem. Now that
hits actually skip work, a sibling app dir under the same MCPP_HOME — 163 builds
several — can legitimately supply them, which is how it failed on Windows CI:
Cached acme.widget v1.38.1 (2 units)
FAIL: 163_identity_first_resolution.sh
82 is the more important one. Its NEGATIVE check ("widget must not be pulled when
the feature is inactive") grepped only `Compiling widget`, so a wrongly-pulled
dependency whose objects happened to be cached would announce `Cached widget` and
pass. Both directions now match either verb through one `pulled()` helper, so the
positive cannot be too narrow and the negative cannot be too weak.
25 and 48 grep the ROOT package's Compiling line, which is never cached; left
alone.
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
2 participants
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.
e2e 170 断言 staging 源在
${MCPP_HOME:-$HOME/.mcpp}/build-cache/v1之下。这个在 bash 里把路径重推一遍的做法对 self-contained 安装是错的 —— 那种形态下解包出来的树本身就是 home，而它正是每个 release tarball 与每次xlings install mcpp的形态。用释出的 2026.7.30.2 二进制跑整套 e2e 时它挂了，而二进制是对的：
CI 看不到这个：被测二进制在
target/<triple>/<fp>/bin/mcpp，而mcpp.home::root()刻意把带target祖先的路径从 self-contained 探测里排除掉了。所以这条断言只在「拿装好的 mcpp 跑 e2e」时才misfire —— 而那恰好就是发版后的全生态验证要做的事。改为从
mcpp cache dir读缓存根 —— 这个子命令的存在意义就是让「缓存在哪」只有一个答案。#311 花了一整个模块（mcpp.home）去消除的正是「同一个路径在两处各推一遍」，这里是同一个坑的测试侧残留。已验证两种形态都过：
~/.mcpp）→ OK