Adds strict DDS/RIT migration continuation prompt after IDL files fix
Qt6 Migration CI / migrate (push) Waiting to run
Qt6 Migration CI / migrate (push) Waiting to run
This commit is contained in:
1 file changed
+271
@@ -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
|
||||
Reference in new issue
Block a user