@@ -120,12 +120,27 @@ jobs:
120120 echo "self-hosting $repo @ $ref"
121121 mcpp self config --mirror GLOBAL 2>/dev/null || true
122122 mcpp build --target aarch64-linux-musl
123- m=$(find target/aarch64-linux-musl -type f -path '*/bin/mcpp' | head -1)
123+ # Absolute: it is used again after `cd /tmp/xlings-src` below.
124+ m=$(find "$PWD/target/aarch64-linux-musl" -type f -path '*/bin/mcpp' | head -1)
124125 file "$m" | grep -q "ARM aarch64" || { echo "expected aarch64 mcpp"; exit 1; }
125126 "$m" --version
126127 git clone --depth 1 https://github.com/openxlings/xlings /tmp/xlings-src
127128 cd /tmp/xlings-src
128- mcpp build --target aarch64-linux-musl
129+ # "$m", not `mcpp`: the just-built binary is the code under review,
130+ # and building xlings with the INSTALLED one meant this half of the
131+ # gate never saw the PR — the same defect the clone-ref comment above
132+ # records, one line further down. It surfaced the same way: a fix for
133+ # an aarch64-only failure in exactly this build could not be
134+ # validated here, because the binary running it predated the fix.
135+ #
136+ # MCPP_HOME must be carried over explicitly: mcpp derives it from the
137+ # BINARY's location, so a binary sitting in /tmp/mcpp-src/target would
138+ # otherwise adopt an empty home and re-bootstrap the whole ecosystem
139+ # instead of reusing what the fresh-install steps above provisioned.
140+ export MCPP_HOME=$(mcpp self env | awk -F'= *' '/^MCPP_HOME/{print $2; exit}')
141+ echo "reusing MCPP_HOME=$MCPP_HOME"
142+ test -d "$MCPP_HOME" || { echo "could not determine MCPP_HOME"; exit 1; }
143+ "$m" build --target aarch64-linux-musl
129144 x=$(find target/aarch64-linux-musl -type f -path '*/bin/xlings' | head -1)
130145 file "$x" | grep -q "ARM aarch64" || { echo "expected aarch64 xlings"; exit 1; }
131146 "$x" --version
0 commit comments