mirror of
https://github.com/brazilofmux/tinymux
synced 2026-08-13 00:23:11 -04:00
No description
0a934a7d78
Two remainders from #2025. ## date_scan.cpp was unguarded hooks/pre-commit knew about four Ragel outputs; mux/lib/date_scan.cpp was absent from GENERATED_GENS entirely, so it could be hand-edited and committed without its .rl and nothing objected -- while being listed in docs/generated-files.md and shipped via unix/TOC.patchable. Added to all three parallel arrays, which now hold 27 each. Verified by alignment rather than by count: equal lengths prove nothing about correspondence, so the check confirms every ragel triple's basenames match and its rule lives in the same directory as its output. Then exercised: staging date_scan.cpp alone is now blocked, naming date_scan.rl as its source. ## Six more outputs carried #line #2025's scope was right for what the mux build regenerates and dounix.sh ships, but these have live rules of their own and could still dirty a tree: testcases/tools/unformat.c 28 testcases/tools/Makefile (%.c: %.rl) testcases/tools/reformat.c 23 same ragel/trigger_match.c 16 ragel/Makefile tools/ansify/ansify.c 19 tools/ansify/Makefile (make regen) client/tf/src/script_lex.cpp 67 client/tf/CMakeLists.txt client/tf/src/input_lex.cpp 62 same The issue reported "no rule found" for trigger_match.c and ansify.c. Both were wrong: ragel/Makefile:25 generates trigger_match.c on dependency, and tools/ansify/Makefile has an explicit `regen` target. Neither is inert -- ansify's is opt-in rather than implicit, which is why it reads as absent. Each regenerated through its OWN rule rather than by running sed by hand, so the rule is what is under test. All six are idempotent across a second regeneration, and the diffs are 215 deletions, every one a #line, nothing added. ragel/color_ops.c is generated from the same ../mux/lib/color_ops.rl as the shipped copy but is not tracked, so it could not dirty anything; its rule gets the strip anyway, so the two generations of one source cannot disagree if it is ever checked in. client/tf could not be built here -- src/regex_utils.h needs pcre2.h, which is not on that target's include path on macOS -- but that is a pre-existing gap unrelated to this change. The Ragel custom commands themselves DID run (cmake configure succeeds once NCURSESW_LIB is pointed at a macOS ncurses), and both outputs came back stripped, so the CMake edit is exercised rather than assumed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| client | ||
| color | ||
| debian | ||
| docker | ||
| docs | ||
| hooks | ||
| mux | ||
| parser | ||
| ragel | ||
| sgp | ||
| specs | ||
| testcases | ||
| tests | ||
| tools | ||
| unix | ||
| utf | ||
| win32 | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| AGENTS.md | ||
| CLAUDE.md | ||
| CONTRIBUTING.md | ||
| dounix.sh | ||
| dowin32.sh | ||
| GEMINI.md | ||
| LICENSE | ||
| Makefile | ||