6.1 KiB
6.1 KiB
Hier ist der angepasste Prompt mit beiden Anweisungen:
Setze die Qt5->Qt6-Migration fort und bearbeite strikt nur die Forward-Declaration-Konsolidierung im Qt6-Baum.
Spezielle Aufgabe:
Es existieren zwei Verzeichnisse mit identischem Inhalt:
- a) /workspace/include
- b) /workspace/qt-migration-legatus/qt6-after/qt6-migrated-legatus/include
Aktuell werden trotz identischem Inhalt noch immer beide benötigt.
Ziel:
- bereinige alle direkt betroffenen CMake-Skripte, `#include`-Stellen und Tool-/Codegenerator-Aufrufe so, dass **nur noch b)** benötigt wird:
- /workspace/qt-migration-legatus/qt6-after/qt6-migrated-legatus/include
- erst wenn dieser Zustand sicher erreicht ist, lösche a):
- /workspace/include
- belasse danach ausschließlich b)
Wichtiger Container-Kontext:
- `/workspace` ist ein **Mount im Validierungs-Docker-Container**
- der maßgebliche Validierungsweg dafür ist:
- `/workspace/qt-migration-legatus/qt6-after/qt6-migrated-legatus/docker_build.sh`
- berücksichtige deshalb, dass alle Pfade im Validierungskontext containerbezogen unter `/workspace` aufgelöst werden müssen
Zusätzliche Pflicht:
- passe **auch den Migrations-Docker-Container** in
- `/workspace/app/Dockerfile`
minimal mit an, soweit es für diese Umstellung nötig ist, damit die Migration **nicht nur validierbar ist, sondern anschließend auch weiterlaufen kann**
- behandle also:
- `/workspace/app/Dockerfile` als Migrationscontainer
- `/workspace/qt-migration-legatus/qt6-after/qt6-migrated-legatus/docker_build.sh` als Validierungscontainer nach einem Migrationsschritt
Harte Regeln:
- nur diese Konsolidierungsaufgabe bearbeiten
- keine Refactorings
- keine opportunistischen Fixes
- keine fachlogischen Änderungen
- keine Änderungen im Legacy-Tree
- keine neuen Stubs, Wrapper, Redirect-Header oder Kopien erzeugen
- keine parallele Alt-/Neu-Struktur beibehalten
- keine Scheinlösung über zusätzliche Include-Pfade, die beide Verzeichnisse weiter unterstützen
- keine Workarounds, die a) indirekt weiter voraussetzen
Pflichtanalyse:
- prüfe, an welchen Stellen a) noch direkt oder indirekt referenziert wird
- prüfe:
- `CMakeLists.txt`
- cmake-Include-Dateien
- `target_include_directories(...)`
- `include_directories(...)`
- `#include`-Pfade
- Custom Commands
- Generator-/Tool-Aufrufe
- Arbeitsverzeichnisse (`WORKING_DIRECTORY`)
- Skripte mit hart codierten Pfaden
- Docker-bezogene Aufrufe oder Mount-Annahmen
- identifiziere auch implizite Abhängigkeiten, z. B. falsche relative Pfade oder Generatoren, die im Workspace-Root nach `include` suchen
Pflichtumsetzung:
- ändere alle direkt betroffenen Pfade strikt auf b):
- /workspace/qt-migration-legatus/qt6-after/qt6-migrated-legatus/include
- passe Includes minimal so an, dass nur noch b) verwendet wird
- passe CMake-Pfade minimal so an, dass nur noch b) eingebunden wird
- passe Tool-/Codegenerator-Aufrufe minimal so an, dass nur noch b) als Input-/Include-/Suchpfad verwendet wird
- passe bei Bedarf auch Mount-/Container-bezogene Pfadannahmen in den betroffenen Docker-Kontexten minimal an
- stelle sicher, dass keine Build- oder Migrationsstelle mehr a) voraussetzt
Löschregel:
- lösche a) erst dann, wenn nachweislich gilt, dass Configure, Build und ggf. Codegenerierung ohne a) funktionieren
- nicht vorher
- nach erfolgreicher Umstellung darf nur noch b) verbleiben
Strikte CMake-/Pfadregeln:
- bevorzuge ursächliche Korrekturen
- bevorzuge `target_include_directories(...)` gegenüber globalen Sammellösungen, sofern minimal möglich
- keine künstlichen Fallbacks
- keine Pfadverdopplungen
- keine zusätzliche Kompatibilitätsschicht für a)
- keine neuen globalen Variablen, wenn eine lokale Korrektur ausreicht
Tool-/Codegenerator-Regeln:
- prüfe explizit, ob Generatoren oder Hilfstools a) als Include-, Input-, Template- oder Output-Bezug verwenden
- korrigiere diese Aufrufe an der Ursache
- keine Fake-Inputs
- keine stillschweigende Rückfallebene auf a)
Docker-Regeln:
- Validierungscontainer:
- `/workspace/qt-migration-legatus/qt6-after/qt6-migrated-legatus/docker_build.sh`
- Migrationscontainer:
- `/workspace/app/Dockerfile`
- beide Kontexte müssen nach der Änderung konsistent mit nur noch b) arbeiten
- ändere diese Container-Kontexte nur minimal und nur soweit nötig, damit:
- die Validierung funktioniert
- die eigentliche Migration danach weiterlaufen kann
Validierung:
- nutze `/workspace/qt-migration-legatus/qt6-after/qt6-migrated-legatus/docker_build.sh` als primären Validierungsweg
- validiere mit mindestens:
1. Configure
2. Build
3. Nachweis, dass a) nicht mehr benötigt wird
- prüfe zusätzlich, dass notwendige Anpassungen im Migrationscontainer unter `/workspace/app/Dockerfile` konsistent sind
- wenn sinnvoll:
- a) vor dem finalen Validierungslauf entfernen oder unzugänglich machen, um zu beweisen, dass nur b) benötigt wird
Erfolgskriterien:
- alle relevanten CMake-Skripte, Includes und Tool-/Codegenerator-Aufrufe verwenden nur noch b)
- Validierungscontainer und Migrationscontainer sind konsistent auf diese Struktur angepasst
- a) wird nirgends mehr benötigt
- a) wurde anschließend gelöscht
- nur b) bleibt bestehen:
- /workspace/qt-migration-legatus/qt6-after/qt6-migrated-legatus/include
- Build/Configure/ggf. Codegenerierung funktionieren ohne a)
- die Migration kann danach weiterlaufen
- keine Wrapper, Kopien oder Parallelstrukturen
Wenn nicht vollständig lösbar:
- nichts vortäuschen
- a) nicht löschen, falls noch technische Abhängigkeiten bestehen
- als teilweise validiert oder blockiert melden
- exakte Restabhängigkeit auf a) benennen
- angeben, ob der Blocker im Validierungscontainer, im Migrationscontainer oder im Projekt selbst liegt
Abschlussbericht nur kurz:
- validiert, teilweise validiert oder blockiert
- geänderte Dateien
- geänderte CMake-Dateien
- geänderte Include-Stellen
- geänderte Tool-/Generator-Aufrufe
- Anpassungen an `/workspace/app/Dockerfile`
- Anpassungen an `/workspace/qt-migration-legatus/qt6-after/qt6-migrated-legatus/docker_build.sh`
- ob a) gelöscht wurde
- exakte Docker-Kommandos
- verbleibende Blocker oder Risiken