0ff9050eb3
All checks were successful
CI / build-test-release (pull_request) Successful in 6m13s
When crafter-build's stdout is not a TTY (redirected to a file or pipe) the C runtime defaults to full (block) buffering. The progress path is TTY-aware and the in-place redraw flushes explicitly, but the non-TTY append path (`[N/M]` lines), Finalize()'s `Built N steps` line and the `-r` server's `listening on port :N` line all go through block-buffered stdout with no flush. They accumulate in the buffer and only spill at ~4KB boundaries. On a normal build this is hidden because the C runtime flushes stdout at exit. Under `-r` the process never exits — it blocks in its serve loop — so the trailing buffer is never flushed: a redirected log freezes mid-build (or sits at 0 bytes) even though the build finished and the server is already answering. Any tooling that polls the log for `Built …` / `listening …` / `[N/N]` hangs forever. This is the real cause of the frozen log misdiagnosed as a build deadlock in #16. Fix: switch stdout to line buffering at the very top of main(), before any output, only when stdout is not a terminal. Every `\n` then flushes, so the markers reach a redirected log immediately. No behaviour change on a TTY. Kept self-contained in main.cpp using system headers (isatty + setvbuf) rather than a new Crafter::Progress export: the self-hosting exe build compiles main.cpp against the installed/cached Crafter.Build module BMIs, which shadow the freshly built local ones, so a new interface symbol would not be visible without reinstalling crafter-build first. Resolves #18 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| Crafter.Build-Asset.cpp | ||
| Crafter.Build-Clang.cpp | ||
| Crafter.Build-External.cpp | ||
| Crafter.Build-Implementation.cpp | ||
| Crafter.Build-Interface.cpp | ||
| Crafter.Build-Platform.cpp | ||
| Crafter.Build-Progress.cpp | ||
| Crafter.Build-Shader.cpp | ||
| Crafter.Build-Test.cpp | ||
| main.cpp | ||