7.4 KiB
7.4 KiB
Hier ist der angepasste Prompt mit der neuen Vorgabe zu ./not_complaint.txt:
Behebe strikt nur die aktuell auftretenden RTI ndsgen/IDL-Warnungen im Qt6-Migrationsbaum und beachte die Angaben aus diesem Chat als verbindlichen Kontext.
Wichtige Eingabe:
- alle 145 Warnungen liegen in:
- `./not_complaint.txt`
- nutze diese Datei als vollständige und maßgebliche Ausgangsliste der zu untersuchenden Warnungen
- arbeite die Warnungen nicht nur anhand einzelner Beispiele ab, sondern anhand der vollständigen Liste in `./not_complaint.txt`
Beispielhafte Warnungstypen aus dieser Liste:
- doppelt definierte Enumerator-Namen wie `On`, `Off`, `Normal`, `Undefined`
- Bezeichner-Kollisionen mit IDL-Keywords wie `bitMask`, `typeId`, `eventType`
Verbindlicher Kontext:
- die Migration ist noch nicht abgeschlossen
- der Migrationscontainer ist:
- `./app/Dockerfile`
- der Validierungscontainer ist:
- `./qt-migration-legatus/qt6-after/qt6-migrated-legatus/docker_build.sh`
- `/workspace` ist der relevante Mount-Pfad im Validierungscontainer
- frühere IDL-/DDS-Probleme sind zuerst als Pfad-/Codegen-/Artefaktproblem zu behandeln, nicht vorschnell als echter fachlicher IDL-Inhaltsfehler
- Erfolg darf nicht von stale source-tree/build-tree/developer-local Artefakten abhängen
Harte Codegen-Regel:
- `.idl`, `.h` und `.cpp` Dateien, die aus Codegeneratoren entstehen, insbesondere aus:
- RTI / ndsgen
- ktexttemplate-app
müssen aus dem **Build-Folder** erzeugt, inkludiert und verwendet werden
- solche generierten Dateien dürfen **nicht** ins Source-Repository aufgenommen werden
- solche generierten Dateien dürfen **nicht** aus dem Source-Tree konsumiert werden
- Consumer müssen gegen frisch generierte Build-Artefakte kompilieren
- Include-Pfade, Source-Registrierung und Generator-Aufrufe sind entsprechend zu prüfen und falls nötig minimal zu korrigieren
Aufgabe:
- analysiere die vollständige Warnungsliste aus `./not_complaint.txt`
- gruppiere die 145 Warnungen nach Root-Cause-Typen
- finde die kleinste Menge echter Ursachen hinter dieser Gesamtliste
- prüfe zuerst strikt, ob die Warnungen durch falsche Pfade, doppelte Inputs, doppelte Codegen-Quellen, falsche Include-/Import-Reihenfolgen, doppelt referenzierte IDL-Dateien oder Altartefakte entstehen
- behebe die Ursachen robust und minimal
- nur wenn nachweislich echte inhaltliche IDL/XTypes-Konflikte in den real konsumierten Quellen vorliegen, behebe diese minimal und konsistent
Wichtige Diagnose-Priorität:
Behandle die Warnungen zunächst nicht als gesichert fachliche Modellfehler, sondern prüfe zuerst:
- wird dieselbe IDL logisch oder physisch mehrfach in den Build eingespeist?
- werden Inputs zugleich aus alten und neuen Pfaden konsumiert?
- greifen ndsgen-/Generator-Aufrufe noch auf veraltete Verzeichnisse zu?
- existieren doppelte oder redundante enum-/type-Definitionen nur wegen Migrationsartefakten?
- werden generierte oder forward-declaration-nahe Dateien aus dem falschen Ort referenziert?
- werden IDLs mehrfach oder in falscher Reihenfolge importiert?
- hängen die Warnungen von stale generierten Dateien ab?
- liegen generierte `.idl`, `.h` oder `.cpp` fälschlich im Source-Tree oder werden von dort konsumiert?
- sind Build-Ordner-Outputs korrekt in CMake registriert und werden vor der Compilation erzeugt?
Pflichtanalyse:
- lies und nutze `./not_complaint.txt` als vollständige Warnungsquelle
- ermittle daraus wiederkehrende Muster, betroffene Module und wiederholte Symbolnamen
- prüfe alle direkt relevanten `CMakeLists.txt` und cmake-Include-Dateien
- prüfe ndsgen-/RTI-/ktexttemplate-app-Aufrufe
- prüfe `add_custom_command(OUTPUT ...)`, `BYPRODUCTS`, `DEPENDS`, `MAIN_DEPENDENCY`, `WORKING_DIRECTORY`, `COMMAND`, `VERBATIM`
- prüfe `target_sources(...)`, `target_include_directories(...)`, `add_dependencies(...)`
- prüfe betroffene IDL-Dateien, Importketten und generierte Zwischenschritte
- prüfe, ob dieselben Definitionen über unterschiedliche Pfade doppelt gesehen werden
- prüfe explizit, ob generierte Outputs im Build-Ordner landen und von dort konsumiert werden
Harte Regeln:
- nur diese Warnungen und ihre direkte Ursache beheben
- keine opportunistischen Refactorings
- keine Änderungen im Legacy-Tree
- keine Fake-Erfolge
- keine neuen Stubs, Platzhalter oder manuell erfundenen generierten Dateien
- keine pauschale Unterdrückung der Warnungen
- nicht einfach `-strict` abschalten oder Warnungen maskieren
- keine breiten Umbenennungen im gesamten System ohne Nachweis, dass sie wirklich nötig sind
- keine inhaltlichen IDL-Änderungen, solange Pfad-/Codegen-/Artefaktursachen nicht ausgeschlossen sind
- keine generierten `.idl`, `.h`, `.cpp` ins Repository einchecken oder dauerhaft im Source-Tree ablegen
Wenn ein echter Inhaltskonflikt nachgewiesen ist:
- ändere nur die minimal nötigen realen IDL-Quellen
- achte darauf, dass die Änderung IDL/XTypes-konform ist
- bevorzuge kleinste lokale Änderungen, die mehrere Warnungen auf einmal sauber beseitigen
- passe Folgepfade/CMake/Generatoren nur insoweit an, wie für konsistente Generierung nötig
- vermeide weitreichende ABI-/API-Folgen, soweit im Migrationsstand möglich
Container-Regeln:
- Migration muss mit dem Migrationscontainer weiter möglich bleiben:
- `./app/Dockerfile`
- Validierung erfolgt mit:
- `./qt-migration-legatus/qt6-after/qt6-migrated-legatus/docker_build.sh`
- nutze keine Host-Annahmen
- Erfolg muss im Container reproduzierbar sein
Pflichtvalidierung:
- relevanten Build-/Codegen-Zustand bereinigen, sodass stale Artefakte ausgeschlossen sind
- Configure im Validierungscontainer ausführen
- Build im Validierungscontainer ausführen
- vergleiche die Warnungen vor/nachher anhand von `./not_complaint.txt` bzw. neu erzeugtem Build-Output
- nachweisen, dass die Warnungsanzahl sinkt oder die Warnungen vollständig verschwinden
- falls Codegenerierung beteiligt ist, nachweisen, dass die aktuell konsumierten Inputs und Outputs aus dem Build-Folder stammen
- Abschluss-Check:
- `./docker-build.h`
- `BUILD_RTI=OFF ./docker_build.sh`
Erfolgskriterien:
- die 145 Warnungen aus `./not_complaint.txt` wurden vollständig oder root-cause-basiert weitgehend bereinigt
- die Lösung hängt nicht von Altartefakten oder falschen Pfaden ab
- generierte `.idl`, `.h`, `.cpp` werden aus dem Build-Folder erzeugt und von dort konsumiert
- keine solchen generierten Dateien werden ins Source-Repository aufgenommen
- die wichtigsten Root Causes aus `./not_complaint.txt` sind identifiziert und minimal korrigiert
- Validierungscontainer funktioniert
- Migrationscontainer bleibt konsistent für die Fortsetzung der Migration
- keine Scheinlösung durch Warnungsunterdrückung
Wenn nicht vollständig lösbar:
- nichts vortäuschen
- exakt angeben, welche Warnungsgruppen aus `./not_complaint.txt` gelöst wurden und welche nicht
- angeben, ob Projektproblem, Artefaktproblem, Pfadproblem oder Umgebungsproblem
- die verbleibenden Warnungen bzw. Warnungsgruppen präzise benennen
- den exakten Blocker benennen
Abschlussbericht nur kurz:
- validiert, teilweise validiert oder blockiert
- Anzahl Warnungen vorher/nachher
- Root Causes
- geänderte Dateien
- geänderte CMake-/Generator-Aufrufe
- ob `./app/Dockerfile` angepasst wurde
- ob `./qt-migration-legatus/qt6-after/qt6-migrated-legatus/docker_build.sh` angepasst wurde
- exakte Docker-/Build-Kommandos
- Ergebnis von:
- `./docker-build.h`
- `BUILD_RTI=OFF ./docker_build.sh`
- verbleibende Blocker oder Risiken