5.0 KiB
Context
cmd_build schreibt momentan nur .tbc; cmd_run/run_chain besitzen CLI-Exitcodes, Terminal-/PipeHost, Forms-Fortsetzung und RUN-Auflösung. project_io::new_execution ist bereits gemeinsam. TBC steht aktuell auf Version 4 und trägt die benötigten Projekt-/Forms-/Quellortdaten. Der Plan fordert ausdrücklich einen vorkompilierten Runner statt Cargo beim Anwender.
Goals / Non-Goals
Goals: Wiederverwendbarer nativer Export ohne Compilerinstallation beim Anwender, einheitliche Ausführung und prüfbare Zielartefakte.
Non-Goals: JIT/LLVM, Maschinenübersetzung jeder BASIC-Anweisung, Quellcompiler-Neuschreibung, vollständige Cross-Toolchain beim Anwender, Einbettung beliebiger zur Laufzeit per RUN/OPEN/SHELL referenzierter externer Ressourcen.
Decisions
- Bestehende CLI-Ausführung in einen nutzbaren gemeinsamen Runnerpfad überführen; CLI und das kleine vorgebaute Executable
tbrtverwenden dieselbe VM-/Host-/Forms-/RUN-/Drucklogik.tbrtenthält nativ kompilierte VM/Runtime samt Terminal-/Forms-Unterstützung, ohne IDE oder BASIC-Quellcompiler. Eine Vorlage ohne Nutzlast meldet kontrolliert das fehlende Programm und ist kein erfolgreicher Anwenderprogrammstart. Der Runner lädt beim ersten Start und bei RUN ohne Namen sein eingebettetes Kompilat, statt sein Executable als BAS zu kompilieren. Benannte RUN-Ziele behalten die dokumentierte externe Auflösung; diese Abhängigkeiten werden nicht als automatisch eingebettet beworben. - Einen kleinen gemeinsamen Exportbereich unterhalb von CLI/IDE einführen (beispielsweise eigene
tb-export-Crate), weil CLI, Library und IDE denselben Ziel-/Vorlagen-/Publikationsvertrag benötigen. Er erhält für EXE den vollständig verknüpften Projektstand, das Target und den Zielpfad; er hängt nicht von IDE-Dokumenttypen ab. Die IDE adaptiert ihren Revisionsstempel in 04. Kein Hintergrunddienst oder globaler Paketmanager. - Zielmatrix:
x86_64-pc-windows-msvc,aarch64-apple-darwin,x86_64-unknown-linux-gnu,aarch64-unknown-linux-gnu. amd64/arm64 sind Anzeigenamen für x86_64/aarch64. Linux-Systembibliotheksbasis wird mit dem tatsächlichen Builder-Image dokumentiert; Standalone bedeutet eingebettete TB-Runtime, nicht ein kernelunabhängiges oder beliebig altes Linux-Binary. Keine Windows-arm64-/macOS-amd64-Produkte. - Release-Pakete enthalten das passende vorgebaute
tbrt(tbrt.exeauf Windows) als Exportvorlage plus Format-/Runtime-/Zielmetadaten und Integritätsdaten. 06 baut sie in Gitea Actions. 02 macht deren Bau und Prüfung zunächst lokal auf dem jeweiligen Ziel ausführbar. --target akzeptiert nur vorhandene und finalisierbare Zielvorlagen; ohne Voraussetzung gibt es eine klare Verfügbarkeitsdiagnose. Keine stillen Netzdownloads und kein impliziter Cargo-Fallback. - Einen versionierten Nutzlastabschluss mit geprüften Längen/Offset und vorhandenen TBC-Laderprüfungen verwenden; Plattformformat und Runtime-Version werden vor Kopieren und Start abgeglichen. Der alte Dokumentationssatz „Anhängen ist portabel“ reicht nicht als Implementierungsbeleg. Insbesondere Mach-O wird nach dem Einbetten korrekt finalisiert/signiert; die Nutzlastauffindung darf nicht annehmen, dass ein durch Signieren veränderliches Dateiende unverändert bleibt. Native macOS-arm64-Probe und Codesign-Prüfung sind ein frühes Umsetzungstor, nicht erst Release-Nacharbeit. Eine unterstützte systemeigene Signierhilfe ist keine Compiler-/Linker-Toolchain. Cross-Export wird nur angeboten, soweit Vorlage und Finalisierung auf dem Host tatsächlich verfügbar sind.
- In ein temporäres Geschwisterziel schreiben, validieren/finalisieren und erst dann veröffentlichen. No-clobber und ausdrückliches Ersetzen auch beim finalen Dateischritt erzwingen, Quellen/Manifest/Includes schützen und Abbruch vor Veröffentlichung beachten. Der Vertrag wird von TBL-Export,
tbc linkund IDE wiederverwendet. P-Code-Linken undtbc linkentstehen in 03; hier genügt das bereits vollständig verknüpfte TBC. Es gibt keine Rückabhängigkeit von 02 auf 03.
Risks / Trade-offs
- Nachträgliche Binäränderung invalidiert Signaturen → finalisierte Datei auf tatsächlichem Ziel prüfen; Signierung nach Nutzlasteinbau, kein Scheinerfolg. Grundlage: Apple Code Signing.
- Vorlagen aus anderer Runtime-Version → klare Version-/Zielprüfung; Release-Paket enthält zusammengehörige Erzeuger und Vorlagen.
- Vier Ziele auf nur einem Entwicklerrechner → lokale Zielprobe ist ein Teilnachweis; 05/06 verlangen tatsächliche Zielausführung.
- Herauslösen des Runners ändert CLI-Nebenwirkungen → vorhandene CLI-/TBC-/IDE-Parität, Exitcodes, LPRINT und RUN regressionsprüfen.
Migration Plan
TBC-Standardaufruf erhalten. Native Flags mit klarer Optionsdiagnose ergänzen. Dokumentation für Erzeugen, Laufzeitdateien und Systemvoraussetzungen mitliefern. Vorlagen versionieren; inkompatible Mischungen abweisen statt zu erraten. Vorherige Release-Pakete bleiben separat nutzbar.