Decide a build step by its exit code, not by whether it printed #33
No reviewers
Labels
No labels
bug
claude:blocked
claude:done
claude:failed
claude:in-progress
claude:ready
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
Catcrafts/Crafter.Build!33
Loading…
Reference in a new issue
No description provided.
Delete branch "claude/issue-32"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
A compiler warning failed the build, because success was inferred from whether the command printed anything rather than from its exit code. Warnings are only emitted when a translation unit is actually recompiled, so the same unchanged source passed or failed depending on whether its object happened to be up to date — flaky-looking tests locally, and a cold CI checkout surfacing every latent warning in a project at once.
The fix
RunCommandmerged stderr into stdout, discardedpclose's status and returned the text; every compile, link and archive site read "printed something" as "failed". It's gone, replaced byRunBuildCommand, which goes through the existingRunCommandChecked:"", so every caller'sif (!result.empty())error path is unchanged, and any warnings go to the newProgress::Diagnostic(status line cleared, written whole under the progress mutex so parallel compiles don't interleave theirnote:continuations).Every
RunCommandcall site was a build step, so the function is removed outright rather than left around to be reached for again. Covers the paths the issue lists: precompile and BMI→object (Interface), implementation units (Implementation), C and CUDA, every link/archive/shared-library step,BuildStdPcm, andLoadProject'sproject.cppcompile.Warnings are now shown, which they weren't in either direction before — invisible on an incremental build, fatal on a cold one. Failing on them stays the project's choice via
-WerrorincompileFlags, which then fails the same way every time. README updated to say so.Tests
New
tests/CompilerWarning. The fixture puts a#warningin each kind of source the build compiles — module interface, module implementation, C, consumer — plus an unknown-zvalue sold.lldwarns on the link step too. It asserts the build succeeds cold (every unit compiling, every warning emitted), succeeds with nothing to do, and succeeds again after each source is touched back into staleness. The staged copy lives outside the repo because the whole test depends on units compiling for the first time.The last pass breaks a source on purpose — "never fails" would satisfy everything above just as well — and asserts both that it fails and that it still reports the compiler's diagnostic.
Verified the test catches the old behaviour: with
RunBuildCommandtemporarily reverted to returning the output regardless, it fails withcold build failed: .../counter.c:4:2: warning: "C source is noisy" [-W#warnings].crafter-build test: 21 passed, 0 failed (from acrafter-build clean).crafter-build lint: clean, 44 files, 17 rules. The wasi example still builds forwasm32-wasip1.Resolves #32