Crafter.Build/implementations/main.cpp

49 lines
1.8 KiB
C++
Raw Normal View History

2026-04-27 07:04:42 +02:00
/*
Crafter® Build
Copyright (C) 2026 Catcrafts®
Catcrafts.net
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License version 3.0 as published by the Free Software Foundation;
This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with this library; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
fix: line-buffer stdout when redirected so progress/readiness lines flush 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>
2026-06-01 14:42:33 +00:00
#include <cstdio>
#if defined(_WIN32)
#include <io.h>
#ifndef STDOUT_FILENO
#define STDOUT_FILENO _fileno(stdout)
#endif
#define CRAFTER_MAIN_ISATTY _isatty
#else
#include <unistd.h>
#define CRAFTER_MAIN_ISATTY isatty
#endif
2026-04-27 07:04:42 +02:00
import std;
import Crafter.Build;
int main(int argc, char** argv) {
fix: line-buffer stdout when redirected so progress/readiness lines flush 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>
2026-06-01 14:42:33 +00:00
// Line-buffer stdout when it is not a terminal. Must run before any stdout
// write. When stdout is a regular file or pipe the C runtime defaults to
// full (block) buffering, so the append-only progress lines ("[N/M]") and
// the trailing "Built … steps" / "listening on port …" lines would sit in
// the buffer and never reach a redirected log — fatal for tooling that
// polls the log for a readiness marker, and worst under -r where the
// process blocks in its serve loop and never returns to flush. A TTY is
// already line-buffered and its in-place redraw path flushes explicitly, so
// only adjust when redirected.
if (CRAFTER_MAIN_ISATTY(STDOUT_FILENO) == 0) {
std::setvbuf(stdout, nullptr, _IOLBF, 0);
}
2026-04-27 07:04:42 +02:00
return Crafter::Run(argc, argv);
}