Phase 6: Native Executables implementieren und Change archivieren
This commit is contained in:
@@ -38,12 +38,12 @@ plant die gesamte Phase 6; es behauptet keine neue Implementation oder Abnahme.
|
||||
| Nr. | Change | Voraussetzungen | Eigenständige Leistung |
|
||||
| --- | --- | --- | --- |
|
||||
| 01 | [Kompatibilität und Leistungsabnahme](proposal.md) | Phase 5 | Reproduzierbarer Abnahmesatz, Fremdkorpus, Inventarbasis und begründeter Performance-Pass |
|
||||
| 02 | [Native Executables](../phase-6-02-native-executables/proposal.md) | 01 | Gemeinsamer Export-/Runnerpfad, vier native Programmziele, sichere Veröffentlichung |
|
||||
| 03 | [P-Code-Bibliotheken und Linker](../phase-6-03-pcode-bibliotheken-und-linker/proposal.md) | 02 | TBL-Format, tbc link, MAK-Einbindung und quellfreie BASIC-Verbraucher |
|
||||
| 04 | [IDE-Exportanbindung](../phase-6-04-ide-exportanbindung/proposal.md) | 02, 03 | Reale Make-Aktionen, TBL-Projektintegration, konsistenter Overlay-/Librarystand und sichere Ergebnisse |
|
||||
| 05 | [Plattformmatrix](../phase-6-05-plattformmatrix/proposal.md) | 01–04 | Tatsächliche Eingabe-/Darstellungs-/Terminalabnahme auf allen Zielen |
|
||||
| 06 | [Gitea Actions und Releases](../phase-6-06-gitea-actions-und-releases/proposal.md) | 01–05 | Vier Actions-Builds, Paketierung, native Paketprüfungen und vollständiger Releasepfad |
|
||||
| 07 | [Dokumentation und Phasenabnahme](../phase-6-07-dokumentation-und-phasenabnahme/proposal.md) | 01–06 | Aktuelle Anleitungen/Hilfe, ausgelieferter Gesamtweg und belegter Phase-6-Abschluss |
|
||||
| 02 | [Native Executables](../2026-09-07-phase-6-02-native-executables/proposal.md) | 01 | Gemeinsamer Export-/Runnerpfad, vier native Programmziele, sichere Veröffentlichung |
|
||||
| 03 | [P-Code-Bibliotheken und Linker](../../phase-6-03-pcode-bibliotheken-und-linker/proposal.md) | 02 | TBL-Format, tbc link, MAK-Einbindung und quellfreie BASIC-Verbraucher |
|
||||
| 04 | [IDE-Exportanbindung](../../phase-6-04-ide-exportanbindung/proposal.md) | 02, 03 | Reale Make-Aktionen, TBL-Projektintegration, konsistenter Overlay-/Librarystand und sichere Ergebnisse |
|
||||
| 05 | [Plattformmatrix](../../phase-6-05-plattformmatrix/proposal.md) | 01–04 | Tatsächliche Eingabe-/Darstellungs-/Terminalabnahme auf allen Zielen |
|
||||
| 06 | [Gitea Actions und Releases](../../phase-6-06-gitea-actions-und-releases/proposal.md) | 01–05 | Vier Actions-Builds, Paketierung, native Paketprüfungen und vollständiger Releasepfad |
|
||||
| 07 | [Dokumentation und Phasenabnahme](../../phase-6-07-dokumentation-und-phasenabnahme/proposal.md) | 01–06 | Aktuelle Anleitungen/Hilfe, ausgelieferter Gesamtweg und belegter Phase-6-Abschluss |
|
||||
|
||||
Die Reihenfolge 01 bis 07 ist gültig. Native Zielprüfungen in 02/03/05 sind
|
||||
vor 06 zunächst lokal auf passenden Prüfrechnern ausführbar; 06 automatisiert
|
||||
|
||||
@@ -22,4 +22,4 @@ Keine. TBC bleibt ein gesondertes Ausgabeformat mit unverändertem Sprachvertrag
|
||||
|
||||
## Impact
|
||||
|
||||
CLI-Build-/Runnerpfad in `crates/tb-cli/src/main.rs`, gemeinsame Projekt-/VM-Erzeugung, neuer wiederverwendbarer Export-/Runnerbereich, Release-Vorlagen und native Prozessprüfungen. Keine LLVM-/JIT-Umstellung. Referenzfälle aus [01](../archive/2026-09-07-phase-6-01-kompatibilitaet-und-leistungsabnahme/proposal.md); Auslieferung in 06. Der gleiche Exportvertrag wird von 03 und 04 verwendet.
|
||||
CLI-Build-/Runnerpfad in `crates/tb-cli/src/main.rs`, gemeinsame Projekt-/VM-Erzeugung, neuer wiederverwendbarer Export-/Runnerbereich, Release-Vorlagen und native Prozessprüfungen. Keine LLVM-/JIT-Umstellung. Referenzfälle aus [01](../2026-09-07-phase-6-01-kompatibilitaet-und-leistungsabnahme/proposal.md); Auslieferung in 06. Der gleiche Exportvertrag wird von 03 und 04 verwendet.
|
||||
@@ -1,19 +1,19 @@
|
||||
## 1. Gemeinsamer Ausführungs- und Exportpfad
|
||||
|
||||
- [ ] 1.1 CLI-Laufsteuerung für Quellen, TBC und eingebettete Kompilate wiederverwendbar machen; bestehende CLI-/IDE-Parität, Forms-Ende, STOP-/Fehlerexitcodes, LPRINT und RUN-Regressionen müssen bestehen.
|
||||
- [ ] 1.2 Ziel-/Runtime-/Vorlagenmetadaten für die vier vereinbarten Targets sowie kompatible Versionen festlegen; negative Tests müssen falsches System, Architektur, Version und fehlende Vorlage konkret abweisen.
|
||||
- [ ] 1.3 Gemeinsame geschützte Ausgabeveröffentlichung implementieren; Konflikt, Schreibfehler, zwischenzeitlich belegtes Ziel und Abbruch müssen ursprüngliche Dateien und Projektdaten erhalten.
|
||||
- [x] 1.1 CLI-Laufsteuerung für Quellen, TBC und eingebettete Kompilate wiederverwendbar machen; bestehende CLI-/IDE-Parität, Forms-Ende, STOP-/Fehlerexitcodes, LPRINT und RUN-Regressionen müssen bestehen.
|
||||
- [x] 1.2 Ziel-/Runtime-/Vorlagenmetadaten für die vier vereinbarten Targets sowie kompatible Versionen festlegen; negative Tests müssen falsches System, Architektur, Version und fehlende Vorlage konkret abweisen.
|
||||
- [x] 1.3 Gemeinsame geschützte Ausgabeveröffentlichung implementieren; Konflikt, Schreibfehler, zwischenzeitlich belegtes Ziel und Abbruch müssen ursprüngliche Dateien und Projektdaten erhalten.
|
||||
|
||||
## 2. Native Programme
|
||||
|
||||
- [ ] 2.1 Das kleine native `tbrt` mit VM/Runtime/Terminal/Forms und versioniertem eingebettetem Kompilat bauen; eine leere Vorlage muss fehlende Nutzlast diagnostizieren, ohne Originalquellen müssen Konsolen- und Forms-Programme laufen, RUN ohne Ziel muss das eingebettete Projekt neu initialisieren.
|
||||
- [ ] 2.2 Nutzlastgrenzen/-versionen prüfen und PE/ELF-/Mach-O-Ausgaben korrekt finalisieren; beschädigte Längen und abgeschnittene Nutzlast müssen ohne Absturz mit Ladefehler enden.
|
||||
- [ ] 2.3 macOS-arm64-Signierung und stabile Nutzlastauffindung nach Finalisierung praktisch belegen; native Ausführung und Signaturprüfung müssen die endgültige Datei akzeptieren, andernfalls keine Exportfreigabe.
|
||||
- [ ] 2.4 `tbc build --exe` mit Ausgabepfad, explizitem Target und Überschreibentscheidung anbinden; CLI-Tests müssen unbekannte Flags abweisen und den bisherigen TBC-Standard unverändert bestätigen.
|
||||
- [ ] 2.5 `tbrt`-Vorlagen-Bauaufrufe für Windows amd64, macOS arm64 und Linux amd64/arm64 bereitstellen; native Header-/Architekturprüfung muss jede Vorlage ihrem deklarierten Target zuordnen.
|
||||
- [x] 2.1 Das kleine native `tbrt` mit VM/Runtime/Terminal/Forms und versioniertem eingebettetem Kompilat bauen; eine leere Vorlage muss fehlende Nutzlast diagnostizieren, ohne Originalquellen müssen Konsolen- und Forms-Programme laufen, RUN ohne Ziel muss das eingebettete Projekt neu initialisieren.
|
||||
- [x] 2.2 Nutzlastgrenzen/-versionen prüfen und PE/ELF-/Mach-O-Ausgaben korrekt finalisieren; beschädigte Längen und abgeschnittene Nutzlast müssen ohne Absturz mit Ladefehler enden.
|
||||
- [x] 2.3 macOS-arm64-Signierung und stabile Nutzlastauffindung nach Finalisierung praktisch belegen; native Ausführung und Signaturprüfung müssen die endgültige Datei akzeptieren, andernfalls keine Exportfreigabe.
|
||||
- [x] 2.4 `tbc build --exe` mit Ausgabepfad, explizitem Target und Überschreibentscheidung anbinden; CLI-Tests müssen unbekannte Flags abweisen und den bisherigen TBC-Standard unverändert bestätigen.
|
||||
- [x] 2.5 `tbrt`-Vorlagen-Bauaufrufe für Windows amd64, macOS arm64 und Linux amd64/arm64 bereitstellen; native Header-/Architekturprüfung muss jede Vorlage ihrem deklarierten Target zuordnen.
|
||||
|
||||
## 3. Abnahme und Übergabe
|
||||
|
||||
- [ ] 3.1 Repräsentative Fälle aus 01 als einzelne Executables in sauberen Verzeichnissen ohne Quellen/TBC/tb/tbc/Rust-Toolchain starten; Ausgabe, Dateieffekte, COMMAND$, Fehler und Terminal-/Pipeverhalten müssen mit CLI übereinstimmen.
|
||||
- [ ] 3.2 Verfügbarkeit und Systemvoraussetzungen einschließlich externer RUN-/OPEN-Ressourcen dokumentieren; fehlende Finalisierungswerkzeuge dürfen keine stille Ersatzdatei erzeugen.
|
||||
- [ ] 3.3 Gemeinsamen Exportvertrag und Zielvorlagen an 03/04/06 übergeben; fokussierte native Tests, Workspace-Regressionen, Clippy, Format- und OpenSpec-Prüfung müssen bestehen, noch ausstehende externe Zielnachweise benannt sein.
|
||||
- [x] 3.1 Repräsentative Fälle aus 01 als einzelne Executables in sauberen Verzeichnissen ohne Quellen/TBC/tb/tbc/Rust-Toolchain starten; Ausgabe, Dateieffekte, COMMAND$, Fehler und Terminal-/Pipeverhalten müssen mit CLI übereinstimmen.
|
||||
- [x] 3.2 Verfügbarkeit und Systemvoraussetzungen einschließlich externer RUN-/OPEN-Ressourcen dokumentieren; fehlende Finalisierungswerkzeuge dürfen keine stille Ersatzdatei erzeugen.
|
||||
- [x] 3.3 Gemeinsamen Exportvertrag und Zielvorlagen an 03/04/06 übergeben; fokussierte native Tests, Workspace-Regressionen, Clippy, Format- und OpenSpec-Prüfung müssen bestehen, noch ausstehende externe Zielnachweise benannt sein.
|
||||
@@ -0,0 +1,141 @@
|
||||
# Verifizierung: phase-6-02-native-executables
|
||||
|
||||
Stand: 2026-09-07, Arbeitsbaum auf `993c3e7638f4819615ce6d1eea2c984afb29a1f2`.
|
||||
Der vorausgehende Change 01 wurde synchronisiert, archiviert und mit diesem
|
||||
Commit auf `origin/main` bestätigt. Dieser Bericht betrifft Change 02.
|
||||
|
||||
## Ergebnis
|
||||
|
||||
| Dimension | Nachweis |
|
||||
| --- | --- |
|
||||
| Vollständigkeit | 11/11 Aufgaben; 4/4 Requirements |
|
||||
| Korrektheit | Alle 6 Spec-Szenarien abgedeckt; native macOS-arm64-Ausführung bestanden |
|
||||
| Kohärenz | Gemeinsamer Runner, bestehende VM/TBC/Forms-Semantik, vorgebaute Runtime und geschützter Export gemäß Design |
|
||||
| Offene Befunde | 0 CRITICAL, 0 WARNING, 0 SUGGESTION |
|
||||
|
||||
Proposal, Design, Tasks, Delta-Spec, betroffene Ausführungspfade und
|
||||
Regressionen wurden geprüft. Keine Prüfdimension übersprungen. Die nach
|
||||
Design ausdrücklich späteren realen Windows-/Linux-Abnahmen sind unten
|
||||
getrennt benannt; sie werden nicht als durchgeführt ausgegeben.
|
||||
|
||||
## Requirement- und Szenariozuordnung
|
||||
|
||||
| Requirement / Szenario | Implementierung und ausgeführter Nachweis |
|
||||
| --- | --- |
|
||||
| Eigenständiges natives Terminalprogramm / Leere Runtime-Vorlage | `crates/tb-runner/src/bin/tbrt.rs:13` liest sein eigenes Executable; `tb_export::embedded` prüft vor VM-Start. Native Probe: leere Vorlage liefert Exit 1 und Nutzlastdiagnose. |
|
||||
| Eigenständiges natives Terminalprogramm / Ausführung auf sauberem Ziel | `crates/tb-export/src/lib.rs:471`, `tests/support/native-abnahme.py`: sieben CLI-/EXE-Vergleiche, darunter ein Forms-/Mehrmodulprojekt mit verschachtelten Includes. Quellen vor EXE-Start gelöscht, separates Arbeitsverzeichnis, PATH leer. Fehlerorte, Anfangswerte, Ausgabe und Dateieffekte identisch. |
|
||||
| Explizites Ausgabeformat und Ziel / Vorlage passt nicht | `crates/tb-cli/src/main.rs:140`: Standard bleibt TBC; explizite EXE-/Target-/Vorlagen-/Ausgabe-/Force-Optionen. `native_build_optionen_sind_explizit_und_tbc_bleibt_standard` sowie Exporttests prüfen unbekannte/doppelte/fehlende Optionen, fremde Systeme/Architekturen, Runtime-/Paket-/TBC-Version, Integrität und fehlende Vorlage. |
|
||||
| Gemeinsame Laufzeitsemantik / Neustart aus dem Executable | `crates/tb-runner/src/lib.rs:10` und `:72` werden von CLI und tbrt benutzt. Native Probe verändert Variable/Datei und führt RUN aus: frische VM, Datei bleibt, COMMAND$ bleibt. Externes TBC-RUN, STOP, Runtimefehler, LPRINT, Eingaben, Forms und Terminalabbruch bestehen ebenfalls. |
|
||||
| Validiertes und sicher veröffentlichtes Artefakt / Beschädigte Nutzlast | `crates/tb-export/src/lib.rs:179`: Container-/Runtime-/TBC-/Targetprüfung, geprüfte Offset-/Längenarithmetik, Prüfsumme und TBC-Validierung. Native Gegenproben für maximale u64-Länge, falsche Version und abgeschnittene Nutzlast enden mit Exit 1/Ladefehler ohne Programmausgabe. |
|
||||
| Validiertes und sicher veröffentlichtes Artefakt / Finalisierung schlägt fehl | `crates/tb-export/src/lib.rs:346`: temporäres Geschwisterziel, Schutzpfade, Abbruch, Zielvergleich und atomare Veröffentlichung. `fehlgeschlagene_native_finalisierung_erhaelt_das_ziel` lässt die tatsächliche native Finalisierung scheitern und prüft Original/Bereinigung. Weitere Gegenproben decken Schreibfehler, Konflikt, nachträglich belegtes Ziel und Abbruch ab. |
|
||||
|
||||
## Behobene Befunde aus der Umsetzung und Verifizierung
|
||||
|
||||
1. **Indirekter Quellcompiler in tbrt.** Designentscheidung 1 fordert einen
|
||||
Runner ohne BASIC-Quellcompiler. Die erste Symbolprüfung fand den Parser
|
||||
über den Watch-/Debugger-Pfad der gemeinsamen VM. `DebugCompiler` bindet
|
||||
den Compiler nun erst bei seiner ausdrücklichen Erzeugung über einen
|
||||
Funktionszeiger (`crates/tb-vm/src/project.rs`). Die VM-API und
|
||||
Debuggerfunktion bleiben erhalten. Erneute Release-Symbolprüfung mit
|
||||
`nm` findet keine Parser-, SourceLoader-, Projektcompiler- oder
|
||||
Debug-Compiler-Implementierungssymbole; IDE-/VM-Debuggertests bestehen.
|
||||
2. **Abbruch während CLI-Export.** Ein nur für Bibliotheksaufrufer vorhandener
|
||||
Abbruchcallback genügte nicht für CLI-Signale. `export_cancel.rs` führt
|
||||
Unix-SIGINT/SIGTERM beziehungsweise Windows-Ctrl+C/Break in diesen
|
||||
Callback. Die native Prozessprobe unterbricht zwei laufende Exporte
|
||||
nach Anlage der temporären Datei: Exit 1, Original unverändert, keine
|
||||
temporäre Ausgabe. Laufzeit-Ctrl+C bleibt beim bestehenden Terminalhost.
|
||||
3. **Native Formatgrenzen.** Gegenproben schärften abgeschnittene Header und
|
||||
fremde ELF-System-ABIs. Kurze Header und andere ABIs als System V/Linux
|
||||
werden abgewiesen. PE übernimmt keine veraltete optionale Prüfsumme;
|
||||
vorhandene Authenticode-Signaturen führen zu einer konkreten Ablehnung.
|
||||
Vier Target-Zuordnungen und beschädigte Header/Nutzlasten sind geprüft.
|
||||
4. **Mach-O-Ende nach Signierung.** Eine reine Dateiende-Annahme wäre nach
|
||||
codesign falsch. Die Implementierung entfernt die vorherige Signatur,
|
||||
erweitert `__LINKEDIT`, signiert nach dem Einbetten und liest vor der
|
||||
Veröffentlichung die fertige Datei erneut. Der Lader benutzt die durch
|
||||
`LC_CODE_SIGNATURE` bezeichnete Grenze und geprüftes Nullpadding.
|
||||
Export, `codesign --verify --strict` und native Ausführung bestehen.
|
||||
|
||||
Keine bestehenden Golden-Dateien oder Inventarverträge wurden geändert.
|
||||
Die CLI-/IDE-Abnahme benutzt weiterhin denselben Ausführungspfad; nur ihre
|
||||
Imports wurden nach Herauslösen des Runners ausdrücklich gemacht.
|
||||
|
||||
## Ausgeführte Gates
|
||||
|
||||
Lokaler Rechner: Apple M5 Max, 128 GiB, macOS 26.6.2 (25G83),
|
||||
`aarch64-apple-darwin`, Rust 1.97.1/Cargo 1.97.1. Release-Profil mit LTO
|
||||
und codegen-units 1. Vorlagen-/Container-Runtime-ABI 1, TBC-Version 4.
|
||||
|
||||
```sh
|
||||
cargo build --locked --release -p tb-cli -p tb-runner -p tb-export
|
||||
python3 tests/support/native-abnahme.py --target aarch64-apple-darwin
|
||||
python3 tests/support/release-abnahme.py --vbdos-repo /tmp/terminalbasic-vbdos-evidence
|
||||
cargo check --locked --target aarch64-unknown-linux-gnu -p tb-cli -p tb-runner -p tb-export
|
||||
openspec validate --all --strict
|
||||
git diff --check
|
||||
```
|
||||
|
||||
| Gate | Ergebnis |
|
||||
| --- | --- |
|
||||
| Native CLI-/EXE-Probe | 7 Vergleichsfälle bestanden: Konsole/COMMAND$/INPUT/LPRINT, RUN-Neustart, STOP, Laufzeitfehler/Export aus TBC, Projekt-/Include-/Dateifehler, Forms-/Mehrmodul-/Include-Projekt und externes TBC-RUN |
|
||||
| Terminal | 4 Unix-PTY-Läufe: CLI und EXE jeweils Eingabe bzw. Ctrl+C; korrekte Exitcodes und Terminalattribute wiederhergestellt |
|
||||
| Veröffentlichung | Überschreibverweigerung und ausdrückliches Ersetzen; echte SIGINT-/SIGTERM-Abbrüche erhalten das Original und entfernen temporäre Dateien |
|
||||
| Ladefehler | 3 beschädigte native Nutzlasten ohne Projektcode-Ausführung abgewiesen; zusätzliche Versions-/Grenz-/Prüfsummen-Gegenproben in Rust |
|
||||
| macOS-Signierung | Alle finalisierten Vergleichsprogramme strikt geprüft und nativ gestartet |
|
||||
| Workspace | 613 Tests plus 1 Offline-Kindprozesstest bestanden, 0 fehlgeschlagen; 2 beabsichtigte Ignores |
|
||||
| Öffentlicher Pflichtnachweis | Separat 3 Tests bestanden, darin 7 Einstiege × 2 Läufe von cout/vbdos bei `1cdd2b32b829fe1721d0b6aecc433abc47a96fb6` |
|
||||
| Inventar | 845 Einträge: 795 implementiert, 0 offen, 50 deklarierte Non-Features; keine Umklassifizierung |
|
||||
| Clippy / Format | Workspace/all-targets mit `-D warnings` und Formatprüfung bestanden |
|
||||
| OpenSpec | 30 Specs/Changes strikt bestanden, 0 fehlgeschlagen; bestehende INFO-Textlängenhinweise |
|
||||
| Linux arm64 | Cargo-Cross-Check bestanden; kein nativer Ausführungsnachweis |
|
||||
| Vorlagen-Builder | `build-runtime.py --target aarch64-apple-darwin --output /tmp/tb-phase6-02-evidence/templates/aarch64-apple-darwin` erfolgreich, native Header/Architektur und Metadaten geprüft |
|
||||
|
||||
Die native Probe setzt PATH bereits beim Export leer; codesign wird über
|
||||
seinen absoluten Systempfad aufgerufen. Die ausgeführten Programme benötigen
|
||||
somit keine auflösbaren Compiler-/Linkerwerkzeuge. Das ist ein isolierter
|
||||
lokaler Prozessnachweis, keine Behauptung eines frisch installierten
|
||||
Betriebssystems. Die externe RUN-Probe enthält bewusst ihr zusätzliches
|
||||
TBC-Laufzeitmodul; die übrigen Programme benötigen keine separate TBC-Datei.
|
||||
|
||||
Beschädigte Mach-O-Proben werden nach der absichtlichen Mutation neu
|
||||
signiert, damit der Nutzlastlader geprüft wird. Eine ungültige native
|
||||
Signatur kann bereits vom Betriebssystem vor main abgewiesen werden.
|
||||
Die lokale Ad-hoc-Signatur beweist Ausführbarkeit, keine Notarisierung.
|
||||
|
||||
Das finale macOS-tbrt ist 3.022.416 Bytes groß. `otool -L` weist ausschließlich
|
||||
`/usr/lib/libiconv.2.dylib` und `/usr/lib/libSystem.B.dylib` als dynamische
|
||||
Abhängigkeiten aus; keine separate Terminal-Basic-Runtime und keine IDE.
|
||||
|
||||
## Leistungsregression der gemeinsamen VM
|
||||
|
||||
Die unveränderten Benchmarks aus Change 01 wurden im vollständigen
|
||||
Abnahmelauf erneut ausgeführt. Modul: 1,20 ms bei Budget < 50 ms; Projekt
|
||||
mit 49.760 Zeilen: 100 ms bei Budget < 1.000 ms. Inkrementelle Mediane:
|
||||
0,72 ms und 20,62 ms. VM: INTEGER 1.193 ms, DOUBLE 556 ms, SUB 138 ms,
|
||||
Strings 110 ms. Gegenüber der dokumentierten Basis 1.217/572/139/109 ms
|
||||
kein relevanter Leistungsrückschritt; keine Performance-Optimierung.
|
||||
|
||||
## Übergabe und bewusst spätere Zielnachweise
|
||||
|
||||
[Native Executables](../../../../docs/native-executables.md) dokumentiert
|
||||
CLI-Optionen, Vorlagenherstellung für alle vier vereinbarten Triples,
|
||||
Metadaten/Container, öffentliche Export-API und Systemvoraussetzungen.
|
||||
`tbrt` lädt externe RUN-Ziele als vorkompilierte TBC; Quellen benötigen die
|
||||
vorherige Übersetzung durch tbc. RUN-/OPEN-/ISAM-/SHELL-Ressourcen werden
|
||||
nicht automatisch eingebettet. Diese Grenze folgt dem geplanten Runner
|
||||
ohne BASIC-Quellcompiler und ist ausdrücklich sichtbar.
|
||||
|
||||
Die tatsächliche Windows-amd64- und Linux-amd64/arm64-Ausführung,
|
||||
Windows-Terminal-/Abbruchprüfung, konkrete glibc-Builderbasis sowie vier
|
||||
Gitea-Releasepakete bleiben gemäß Design bei Changes 05/06. Change 02 liefert
|
||||
Bauaufrufe, Header-/Architekturprüfung und lokalen macOS-Nativnachweis.
|
||||
TBL/Linker und IDE-Anbindung verwenden denselben Exportvertrag in 03/04.
|
||||
|
||||
Lokale Rohprotokolle: `/tmp/tb-phase6-02-evidence/`, insbesondere
|
||||
`native.log`, `release-abnahme.log`, `export-tests.log`,
|
||||
`linux-arm64-check.log` und `template-build.log`. Alle wesentlichen
|
||||
Resultate und reproduzierbaren Aufrufe stehen zusätzlich in diesem Bericht.
|
||||
Am 2026-09-07 wurden die vier Requirements in die Hauptspezifikation
|
||||
`native-executables` synchronisiert, alle 25 Hauptspezifikationen strikt
|
||||
validiert und Change 02 archiviert.
|
||||
@@ -22,4 +22,4 @@ Keine. TBL ist eine additive Projekt-/Buildfähigkeit; die Anpassung der bisheri
|
||||
|
||||
## Impact
|
||||
|
||||
`tb-vm/src/project.rs`, `bytecode.rs`, `project_io.rs`, Frontend-Deklarationsimport und `tb-cli/src/main.rs`; Wiederverwendung der sicheren Veröffentlichung und `tbrt`-Verpackung aus [02](../phase-6-02-native-executables/proposal.md). Abhängigkeit: 02. IDE-Dokumentmodell, Ausführung, Debugger und Make-Anbindung folgen in 04; plattformübergreifende Verbraucherprüfungen in 05/06, Dokumentation und Gesamtabnahme in 07. Dieser Entwurf ersetzt den noch nicht implementierten Entwurf `phase-6-03-native-bibliotheken` vollständig.
|
||||
`tb-vm/src/project.rs`, `bytecode.rs`, `project_io.rs`, Frontend-Deklarationsimport und `tb-cli/src/main.rs`; Wiederverwendung der sicheren Veröffentlichung und `tbrt`-Verpackung aus [02](../archive/2026-09-07-phase-6-02-native-executables/proposal.md). Abhängigkeit: 02. IDE-Dokumentmodell, Ausführung, Debugger und Make-Anbindung folgen in 04; plattformübergreifende Verbraucherprüfungen in 05/06, Dokumentation und Gesamtabnahme in 07. Dieser Entwurf ersetzt den noch nicht implementierten Entwurf `phase-6-03-native-bibliotheken` vollständig.
|
||||
|
||||
43
openspec/specs/native-executables/spec.md
Normal file
43
openspec/specs/native-executables/spec.md
Normal file
@@ -0,0 +1,43 @@
|
||||
# native-executables Specification
|
||||
|
||||
## Purpose
|
||||
|
||||
Ermöglicht die Erzeugung und Ausführung eigenständiger nativer Terminalprogramme mit eingebettetem Terminal-Basic-Projekt und Runtime.
|
||||
|
||||
## Requirements
|
||||
|
||||
### Requirement: Eigenständiges natives Terminalprogramm
|
||||
`tbc build --exe` SHALL ein natives Terminal-Executable für Windows amd64, macOS arm64, Linux amd64 oder Linux arm64 erzeugen. Die vorgebaute `tbrt`-Vorlage SHALL die nativ kompilierte VM und Runtime einschließlich Terminal-/Forms-Unterstützung enthalten und das eingebettete BASIC-Programm als P-Code ausführen. Das Ergebnis SHALL auf dem ausgewiesenen Ziel ohne Quellprojekt, separate TBC-Datei oder separat installiertes tbrt/tb/tbc laufen. Sowohl Erzeugung aus ausgelieferten Vorlagen als auch Ausführung SHALL ohne Compiler-/Linker-Toolchain beim Anwender möglich sein; dokumentierte Betriebssystemkomponenten dürfen erforderlich bleiben.
|
||||
|
||||
#### Scenario: Leere Runtime-Vorlage
|
||||
- **WHEN** tbrt ohne eingebettetes Programm als Vorlage gestartet wird
|
||||
- **THEN** diagnostiziert es kontrolliert die fehlende Nutzlast und behauptet keinen erfolgreichen Programmstart
|
||||
|
||||
#### Scenario: Ausführung auf sauberem Ziel
|
||||
- **WHEN** ein Mehrmodul-/Formular-/Include-Projekt exportiert und allein sein Executable in ein Verzeichnis ohne Quellen und ohne tb/tbc übertragen wird
|
||||
- **THEN** läuft es auf dem passenden Zielsystem als Terminalprogramm mit denselben Anfangseigenschaften, Ausgaben und Fehlerorten
|
||||
|
||||
### Requirement: Explizites Ausgabeformat und Ziel
|
||||
Der bestehende Aufruf `tbc build <Quelle>` SHALL weiterhin TBC erzeugen. Native Erzeugung SHALL eine eindeutige Ziel-/Ausgabewahl und Überschreibentscheidung erlauben. Ungültige Optionen, nicht unterstützte Zielkombinationen, fehlende Vorlagen und inkompatible Runtime-Versionen MUST vor Veröffentlichung einer Zieldatei mit konkreter Diagnose abgewiesen werden. Ein fremdes Hostformat MUST NOT stillschweigend das angeforderte Zielformat ersetzen.
|
||||
|
||||
#### Scenario: Vorlage passt nicht
|
||||
- **WHEN** eine Windows-amd64-Ausgabe mit einer Linux- oder inkompatiblen Runtime-Vorlage angefordert wird
|
||||
- **THEN** scheitert der Export unter Erhalt der bisherigen Zieldatei und nennt den Ziel-/Versionskonflikt
|
||||
|
||||
### Requirement: Gemeinsame Laufzeitsemantik
|
||||
Native Programme SHALL bei denselben Hostereignissen, Anfangsdateien, Größen und COMMAND$ dieselben Sprach-, Forms-, Datei-, Druck- und Fehlerresultate wie der CLI-Lauf liefern. STOP, Abbruch und Laufzeitfehler SHALL die dokumentierten CLI-Exitcodes erhalten. RUN ohne Ziel SHALL den eingebetteten Anfangsstand neu starten; explizite externe RUN-Ziele SHALL weiter ausdrücklich benötigte Laufzeitdateien sein.
|
||||
|
||||
#### Scenario: Neustart aus dem Executable
|
||||
- **WHEN** das native Programm Variablen und Dateien verändert und danach RUN ohne Programmziel ausführt
|
||||
- **THEN** startet es sein eingebettetes Projekt mit sauberem VM-Anfangszustand und benötigt dafür keine ursprüngliche BAS-/FRM-/MAK-Datei
|
||||
|
||||
### Requirement: Validiertes und sicher veröffentlichtes Artefakt
|
||||
Der Export SHALL Nutzlastgrenzen, Container-/Runtime-Version und Zielformat prüfen und erst ein vollständiges Artefakt am gewählten Ziel veröffentlichen. Fehler und Abbruch SHALL vorhandene Ziele erhalten und temporäre Ausgaben beseitigen. Ausführungsrechte sowie die für lokale Ausführbarkeit notwendigen Plattform-Metadaten und Signaturen SHALL nach dem Einbetten gültig sein.
|
||||
|
||||
#### Scenario: Beschädigte Nutzlast
|
||||
- **WHEN** ein erzeugtes Programm mit abgeschnittener oder ungültiger eingebetteter Nutzlast gestartet wird
|
||||
- **THEN** endet es mit verständlicher Ladefehlermeldung ohne Zugriff außerhalb der Nutzlast und ohne Ausführung von Projektcode
|
||||
|
||||
#### Scenario: Finalisierung schlägt fehl
|
||||
- **WHEN** die plattformspezifische Finalisierung eines Exports fehlschlägt
|
||||
- **THEN** wird kein Erfolg gemeldet und eine vorhandene Zieldatei bleibt unverändert
|
||||
Reference in New Issue
Block a user