François
af36f7c150
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>
14 lines
514 B
C++
14 lines
514 B
C++
#ifndef _FRONTEND_MAIN_HPP_
|
|
#define _FRONTEND_MAIN_HPP_
|
|
|
|
class Frontend;
|
|
|
|
// Shared process entry point, frontend-agnostic. Parses argv
|
|
// (--source / --restore / --batch / --commands-md / --help), drives `fe`
|
|
// through the boot commands and then either dumps output (batch) or enters its
|
|
// event loop, and returns the process exit code. Each frontend's main() just
|
|
// constructs its concrete Frontend and forwards to this.
|
|
int frontend_main(int argc, char **argv, Frontend &fe);
|
|
|
|
#endif // _FRONTEND_MAIN_HPP_
|