273 lines
8.1 KiB
Markdown
273 lines
8.1 KiB
Markdown
# 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
|
||
- in `./app/Dockerfile.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
|