lifemaps/qt6-migration-pipeline

0 Fork 0

Files

T

torsten b53ab2f8c9

Qt6 Migration CI / migrate (push) Waiting to run

Details

Adds strict DDS/RIT migration continuation prompt after IDL files fix

2026-09-07 21:43:41 +02:00

8.1 KiB

Raw Blame History

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:

Wo werden Generator-Inputs gelesen?
Wo werden Generator-Outputs geschrieben?
Welche Targets konsumieren welche generierten Dateien?
Sind Outputs in OUTPUT / BYPRODUCTS korrekt deklariert?
Sind Consumer via DEPENDS / add_dependencies(...) korrekt hinter die Generierung geschaltet?
Sind generierte .cpp wirklich in target_sources(...) enthalten?
Sind generierte Header über Build-Ordner-Include-Pfade erreichbar?
Zeigt irgendein Include-, Custom-Command- oder Tool-Pfad noch in den Source-Tree statt in den Build-Tree?
Werden alte Artefakte bevorzugt gefunden, weil die Include-Reihenfolge falsch ist?
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:

leerer/neuer Build-Ordner
alte relevante Generator-Artefakte entfernt oder ausgeschlossen
Generator lief im aktuellen Build wirklich
neue Outputs wurden im Build-Ordner erzeugt
Consumer kompilierten gegen diese neuen Build-Ordner-Dateien
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:

Configure
Build
Codegen-Nachweis
ggf. Tests
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

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

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

CMake-/Target-/Codegen-Analyse
Pfadtrennung Source vs. Build prüfen
Generator-Output-Orte korrigieren
Dependency-Order korrigieren
Include-Pfade korrigieren
generierte .cpp sauber registrieren
Clean Docker Build
Rebuild-Beweis
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

8.1 KiB Raw Blame History Unescape Escape