diff --git a/prompts/remove-idl-warnings.prompt.md b/prompts/remove-idl-warnings.prompt.md new file mode 100644 index 000000000..491fc3896 --- /dev/null +++ b/prompts/remove-idl-warnings.prompt.md @@ -0,0 +1,135 @@ +Hier ist der **angepasste Prompt** mit der neuen Vorgabe zu `./not_complaint.txt`: + +```text +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 +``` diff --git a/qt-migration-legatus b/qt-migration-legatus index eb02c1f00..be912de9d 160000 --- a/qt-migration-legatus +++ b/qt-migration-legatus @@ -1 +1 @@ -Subproject commit eb02c1f001096c12d45c69f8f520c291b05ab890 +Subproject commit be912de9d6668e213f09fee8206df15eedbb348c