# 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