From b53ab2f8c970eef0fcdcfd4c236a0068bf26def3 Mon Sep 17 00:00:00 2001 From: twi-devel Date: Mon, 7 Sep 2026 21:43:41 +0200 Subject: [PATCH] Adds strict DDS/RIT migration continuation prompt after IDL files fix --- ...rti-migration-strict-codegen-idl.prompt.md | 271 ++++++++++++++++++ 1 file changed, 271 insertions(+) create mode 100644 prompts/continue-dds-rti-migration-strict-codegen-idl.prompt.md diff --git a/prompts/continue-dds-rti-migration-strict-codegen-idl.prompt.md b/prompts/continue-dds-rti-migration-strict-codegen-idl.prompt.md new file mode 100644 index 000000000..24bb5bba4 --- /dev/null +++ b/prompts/continue-dds-rti-migration-strict-codegen-idl.prompt.md @@ -0,0 +1,271 @@ +# DDS/RTI Migration – Fortführungsprompt (CMake/Codegen strikt) + +## Auftrag +Setze die Qt6-Migration **ausschließlich für `Lts/DDS`** fort: + +- Quelle: `/repo/qt-migration-legatus/qt6-after/qt6-migrated-legatus/Lts/DDS` + +Arbeite autonom bis zu: +- Analyse +- minimalen direkt nötigen Fixes +- Docker-Validierung +- kurzem Abschlussbericht + +**Nicht nachfragen**, außer etwas ist unmöglich, destruktiv oder fehlt. + +--- + +## Harte Begrenzung +- **Nur `Lts/DDS`** +- Legacy-Tree nicht ändern +- keine Geschwistermodule migrieren +- andere Dateien nur anfassen, wenn `Lts/DDS` sonst **nicht konfigurierbar, generierbar, kompilierbar, linkbar oder validierbar** ist +- keine Opportunitäts-Fixes +- keine Refactorings +- keine Stubs +- keine Dummy-/Placeholder-/Fake-Codegen-Dateien + +--- + +## Korrigierte Ausgangslage + +### Qt6 Linguist Tools +Der frühere Punkt **„Qt6 Linguist Tools Missing“ gilt als erledigt**: +- in `docker_build.sh` wurde `qt6-tools-dev-tools` bereits ergänzt + +Diesen Punkt **nicht erneut als Hauptursache annehmen**, außer der aktuelle Docker-Build beweist das Gegenteil. + +### Frühere IDL-Konflikte +Die frühere Annahme **„duplicate symbols in `ProjectDataManagement`“** ist **zuerst als Pfad-/Codegen-/Artefaktproblem zu behandeln**, nicht als gesicherter inhaltlicher IDL-Fehler. + +Hintergrund: +- IDL-Dateien wurden initial **während des Builds generiert** +- wegen Repo-/Commit-Fehler lagen generierte IDL-Dateien zeitweise **fälschlich im Source-Tree** +- diese Source-Tree-IDL-Dateien wurden wieder aus dem Git-Repo entfernt + +--- + +## Zentrale Pflichtannahme +**Generierte Dateien dürfen niemals aus dem Source-Tree konsumiert werden.** + +Das gilt für: +- generierte IDL-Dateien +- generierte `.h` +- generierte `.cpp` + +Stattdessen gilt: + +- IDL-/Codegen-Artefakte müssen im **Build-Ordner** entstehen +- Consumer müssen gegen den **Build-Ordner** kompilieren +- Include-Pfade dürfen nicht stillschweigend auf alte Source-Artefakte zeigen +- Erfolg darf nicht von stale Dateien, lokalen Resten oder versehentlich eingecheckten Generator-Outputs abhängen + +--- + +## Hauptziel +`Lts/DDS` in Qt6 so integrieren, dass die Buildkette **deterministisch** ist, besonders für: + +- CMake-Target-Verkabelung +- Codegenerierung +- RTI/dssgen/KTextTemplate-Einbindung +- Generierungsreihenfolge +- Output-Orte +- Rebuild-Trigger + +--- + +## Primärer Fokus: CMake- und Codegen-Forensik +Wenn Builds scheitern, zuerst **nicht** inhaltlich an Quellcode oder IDL herumkorrigieren, sondern diese Punkte prüfen: + +1. **Wo werden Generator-Inputs gelesen?** +2. **Wo werden Generator-Outputs geschrieben?** +3. **Welche Targets konsumieren welche generierten Dateien?** +4. **Sind Outputs in `OUTPUT` / `BYPRODUCTS` korrekt deklariert?** +5. **Sind Consumer via `DEPENDS` / `add_dependencies(...)` korrekt hinter die Generierung geschaltet?** +6. **Sind generierte `.cpp` wirklich in `target_sources(...)` enthalten?** +7. **Sind generierte Header über Build-Ordner-Include-Pfade erreichbar?** +8. **Zeigt irgendein Include-, Custom-Command- oder Tool-Pfad noch in den Source-Tree statt in den Build-Tree?** +9. **Werden alte Artefakte bevorzugt gefunden, weil die Include-Reihenfolge falsch ist?** +10. **Fehlt `VERBATIM`, `MAIN_DEPENDENCY`, `WORKING_DIRECTORY` oder `GENERATED` dort, wo es für reproduzierbaren Build nötig ist?** + +--- + +## Was konkret zu prüfen und ggf. zu fixen ist +Prüfe insbesondere diese CMake-Mechanismen: + +- `add_custom_command(OUTPUT ...)` +- `BYPRODUCTS` +- `DEPENDS` +- `MAIN_DEPENDENCY` +- `WORKING_DIRECTORY` +- `COMMAND` +- `VERBATIM` +- `target_sources(...)` +- `add_dependencies(...)` +- `set_source_files_properties(... GENERATED ...)` +- `target_include_directories(...)` + +Bevorzuge konsequent: +- `${CMAKE_CURRENT_BINARY_DIR}` +- `${CMAKE_BINARY_DIR}` nur wenn wirklich nötig +- build-tree-nahe Outputs +- keine impliziten Source-Tree-Ausgaben + +--- + +## Strikte Build-Ordner-Regeln +Wenn `Lts/DDS` oder direkt abhängige Buildschritte Dateien generieren, dann gilt: + +### Pflicht +- generierte IDL in den **Build-Ordner** +- generierte Header in den **Build-Ordner** +- generierte Source-Dateien in den **Build-Ordner** +- Konsum dieser Dateien **nur** aus dem Build-Ordner + +### Verboten +- Generator schreibt in den Source-Tree +- Build liest generierte IDL aus dem Source-Tree +- Build liest generierte `.h/.cpp` aus dem Source-Tree +- Build basiert auf bereits vorhandenen Entwickler-Artefakten +- fehlende Generierung wird durch manuell angelegte Dateien kaschiert + +--- + +## Harte Diagnose-Regel bei `pdm.idl` / `pdm_enums.idl` +Falls erneut Fehler mit `pdm.idl`, `pdm_enums.idl` oder ähnlichen Artefakten auftreten, dann **zuerst** beweisen: + +- stammen diese Dateien aus aktueller Build-Generierung? +- liegen sie im Build-Ordner? +- referenzieren CMake oder Generatoren noch den Source-Pfad? +- wird versehentlich ein alter Include-Pfad bevorzugt? +- ist der Fehler ein Artefakt von falscher Output-Location oder falscher Dependency-Order? + +**Nicht zuerst**: +- manuell Enums deduplizieren +- IDL-Inhalte „aufräumen“ +- Fehler als gesicherten Source-Widerspruch behandeln + +Erst wenn zweifelsfrei bewiesen ist, dass der Build korrekt **nur** gegen frisch im Build-Ordner generierte Inputs/Outputs läuft, darf ein echter IDL-Inhaltskonflikt als Root Cause gelten. + +--- + +## No-Fake-Success-Regel +Du darfst `BUILD_RTI=ON` **nicht** als erfolgreich melden, wenn nicht nachweislich gilt: + +1. leerer/neuer Build-Ordner +2. alte relevante Generator-Artefakte entfernt oder ausgeschlossen +3. Generator lief im aktuellen Build wirklich +4. neue Outputs wurden im Build-Ordner erzeugt +5. Consumer kompilierten gegen diese neuen Build-Ordner-Dateien +6. Erfolg hing nicht von alten Source-/Build-/lokalen Artefakten ab + +Wenn einer dieser Punkte nicht bewiesen ist: +- Ergebnis als **nicht vollständig validiert** melden + +--- + +## Docker-Regeln +Einzig autoritatives Dockerfile: + +- `/repo/app/Dockerfile` + +Repo im Container: +- `/repo` + +Erforderlich verfügbar: +- `/repo` +- `/repo/external` +- `/repo/external/rti_connext_dds-7.7.0` +- `./rti_license.dat` read-only gemountet + +Wenn RTI Umgebungsvariablen braucht: +- minimal +- explizit +- keine impliziten Host-Annahmen + +--- + +## Pflichtvalidierung +Wenn unterstützt, beide Varianten validieren: + +### 1. Non-RTI +- `BUILD_RTI=OFF` + +### 2. RTI +- `BUILD_RTI=ON` + +Für jede Variante: +1. Configure +2. Build +3. Codegen-Nachweis +4. ggf. Tests +5. kurzes Ergebnis + +Zusätzlich: +- Clean Build aus leerem Build-Verzeichnis +- Inkrementeller Rebuild nach Änderung eines Generator-Inputs / Templates / einer IDL-Abhängigkeit +- Non-RTI darf keine RTI-Lizenz erzwingen, falls RTI optional ist + +--- + +## Startpunkt +Nutze `/repo`-Pfade und bevorzugt Ninja. + +### BUILD_RTI=OFF +```bash +cmake -S /repo/qt-migration-legatus/qt6-after/qt6-migrated-legatus \ + -B /repo/build-off \ + -G Ninja \ + -DCMAKE_BUILD_TYPE=Debug \ + -DBUILD_RTI=OFF +cmake --build /repo/build-off --parallel +ctest --test-dir /repo/build-off --output-on-failure +``` + +### BUILD_RTI=ON +```bash +cmake -S /repo/qt-migration-legatus/qt6-after/qt6-migrated-legatus \ + -B /repo/build-on \ + -G Ninja \ + -DCMAKE_BUILD_TYPE=Debug \ + -DBUILD_RTI=ON +cmake --build /repo/build-on --parallel +ctest --test-dir /repo/build-on --output-on-failure +``` + +Gezielte Target-Builds zur Ursachenanalyse sind erlaubt, aber am Ende muss die Aussage zur DDS-Integration belastbar sein. + +--- + +## Erwartete Arbeitsreihenfolge +1. CMake-/Target-/Codegen-Analyse +2. Pfadtrennung Source vs. Build prüfen +3. Generator-Output-Orte korrigieren +4. Dependency-Order korrigieren +5. Include-Pfade korrigieren +6. generierte `.cpp` sauber registrieren +7. Clean Docker Build +8. Rebuild-Beweis +9. knapper Abschlussbericht + +--- + +## Abschlussbericht +Nur das Wesentliche: + +- **validiert** oder **blockiert** +- ob RTI / Codegen / KTextTemplate beteiligt war +- ob Generierungs-Timing korrekt war +- ob Output-Platzierung korrekt im Build-Ordner war +- ob `BUILD_RTI=ON` erfolgreich war +- ob `BUILD_RTI=OFF` erfolgreich war +- ob `/repo/external/rti_connext_dds-7.7.0` funktionierte +- ob `./rti_license.dat`-Mapping funktionierte +- exakte Docker-Kommandos +- geänderte Dateien +- je Fehlschlag: + - Kommando + - Kernfehler + - Projektfehler vs. Umgebungsfehler + - Fix +- verbleibender Blocker / Restrisiko