fix(ci): the C-library check read a graph it did not write - #5
Merged
Conversation
The check builds the fixture and then inspects its build.ninja. It selected
that file by globbing `target/*/*/build.ninja` and taking the first one that
declares a device action.
A build directory is named by a fingerprint, so a tree that has been built more
than once holds one per configuration and one per engine or payload version it
was built with. The first in glob order is therefore whichever fingerprint
sorts first, not the one this run produced.
Measured 2026-09-07 on the SYCL example. The check reported
ASSERT-FAIL: no ecosystem C library on the device compiler's search list
from a graph written the previous day by mcpp.plugins 0.2.0, which is the
version before the fix this check exists to guard. The graph the same command
had just written carried both `-isystem` flags and was correct. The check would
have reported success for a broken build just as readily, from a stale
directory that happened to be right.
It is invisible in CI, where the checkout is fresh and every directory under
`target/` comes from the same run. Only an accumulating tree can see it.
`target/` is now removed before the build, so exactly one graph exists to read
and the object of the check is produced by the check. That is what the next
step in ci.yml already does for its own build.
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.
What
tools/check_device_c_library.shbuilds a fixture and then inspects itsbuild.ninja, selecting that file by globbingtarget/*/*/build.ninjaand taking the first one that declares a device action.A build directory is named by a fingerprint, so a tree built more than once holds one per configuration and one per engine or payload version it was built with. The first in glob order is whichever fingerprint sorts first, not the one this run produced.
Measured
2026-09-07, on
examples/09-heterogeneous/sycl/appin the mcpp tree:That graph was written the previous day by
mcpp.plugins0.2.0 — the version before the fix this check exists to guard. The graph the same command had just written (dbd6d29826ff18ba) carried both flags:The check reported a defect in a build that was correct. It would report success for a broken one just as readily, whenever the stale directory happened to be the good one.
Why CI never saw it
The checkout is fresh, so every directory under
target/comes from the same run. Only an accumulating tree can distinguish the two.Fix
target/is removed before the build, so exactly one graph exists to read and the object of the check is produced by the check. The next step inci.ymlalready does this for its own build.