François af36f7c150 Add a Frontend interface; make the process entry frontend-agnostic. ...

main.cpp was entirely TUI-specific (constructed Tui, parsed argv, drove
BootDispatch/DumpOutput/Run directly). Introduce a shared frontends layer so a
second frontend can reuse the whole launch flow:

  - src/frontends/frontend.hpp — abstract Frontend interface (BootDispatch,
    DumpCommandsMd, DumpOutput, Run), header-only, no GUI toolkit, no core dep.
  - src/frontends/frontend_main.{hpp,cpp} — frontend_main(argc, argv, Frontend&):
    all the argv parsing (--source/--restore/--batch/--commands-md/--help) and
    the boot → batch/run flow, driving any frontend through the interface.
  - Tui now implements Frontend (the four methods already matched; just marked
    override).
  - The TUI main.cpp shrinks to: construct Tui, call frontend_main. A second
    frontend's main() is identical with its own Frontend type.

Build: a small GUI-toolkit-free static lib essim_frontend (frontend_main.cpp)
is added at the top level when a frontend is selected, and the essim exe links
it. ESSIM_FRONTEND=none still builds core+tests only (no essim_frontend, no
FTXUI). Binary stays ./build/essim.

Behaviour unchanged across --batch/--commands-md/--help/exit codes; only the
usage text is genericised ("the TUI" → "the interface", "console screen" →
"console") now that the launcher is shared.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-06-03 20:34:29 +02:00

5.9 KiB

Raw Blame History

View Raw