torsten
eba0641150
Qt6 Migration CI / migrate (push) Waiting to run
Entire-Checkpoint: 01M2FHV61FMP98KDRSS0X9YH84
95 lines
4.4 KiB
Markdown
95 lines
4.4 KiB
Markdown
```text
|
|
Setze die Qt5->Qt6-Migration fort und bearbeite strikt nur die ./files.txt aufgelisteten Stub-Dateien im Qt6-Baum.
|
|
|
|
Ausgangslage:
|
|
- die ./files.txt aufgelisteten Dateien wurden während der Migration als STUBS erzeugt
|
|
- die Migration ist noch nicht abgeschlossen
|
|
- /workspace/app/Dockerfile ist der Migrationscontainer
|
|
- /workspace/qt-migration-legatus/qt6-after/qt6-migrated-legatus/docker_build.sh ist der Validierungscontainer nach einem Migrationsschritt
|
|
|
|
Ziel:
|
|
- verschiebe die ./files.txt aufgelisteten Stub-/Forward-Declaration-Dateien physisch in ein gemeinsames Verzeichnis:
|
|
- /workspace/qt-migration-legatus/qt6-after/qt6-migrated-legatus/forward-declarations
|
|
- passe danach die direkt betroffenen Includes und CMake-Build-Skripte minimal so an, dass ausschließlich diese neue physische Ablage verwendet wird
|
|
|
|
Wichtige Klarstellung:
|
|
- es geht ausdrücklich um **physisches Verschieben**
|
|
- keine Wrapper-Header
|
|
- keine Weiterleitungs-Header
|
|
- keine Kopien
|
|
- keine Duplikate
|
|
- keine parallele Alt-/Neu-Struktur
|
|
- keine Kompatibilitätslayer
|
|
- keine Symlinks
|
|
- kein Belassen der bisherigen Stub-Dateien an den alten Orten
|
|
|
|
Harte Regeln:
|
|
- nur die ./files.txt aufgelisteten Stub-Dateien bearbeiten
|
|
- keine Refactorings
|
|
- keine opportunistischen Fixes
|
|
- keine fachlogischen Änderungen
|
|
- keine Änderungen im Legacy-Tree
|
|
- keine neuen Stubs erzeugen
|
|
- keine neuen Placeholder-Dateien erzeugen
|
|
- keine Scheinlösung über zusätzliche Include-Pfade, die alte und neue Orte gleichzeitig sichtbar machen
|
|
- Build und Includes sollen deterministisch nur noch gegen die neue Struktur arbeiten
|
|
|
|
Pflichtanalyse:
|
|
- prüfe jede aufgelistete Datei darauf, ob sie tatsächlich ein Stub-/Forward-Declaration-Artefakt ist
|
|
- falls einzelne gelistete Dateien doch keine solchen Artefakte sind, verschiebe sie nicht blind, sondern dokumentiere sie als Ausnahmen
|
|
- identifiziere Redundanzen und Mehrfachablagen
|
|
- bestimme die minimal nötigen Include-Anpassungen nach dem physischen Verschieben
|
|
- bestimme die minimal nötigen CMake-Anpassungen nach dem physischen Verschieben
|
|
|
|
Pflichtumsetzung:
|
|
- verschiebe die betroffenen Dateien physisch nach:
|
|
- /workspace/qt-migration-legatus/qt6-after/qt6-migrated-legatus/forward-declarations
|
|
- bereinige die alten Pfade so, dass keine alten Stub-Dateien zurückbleiben
|
|
- passe alle direkt betroffenen `#include`-Stellen minimal an
|
|
- passe alle direkt betroffenen `CMakeLists.txt` / cmake-Include-Pfade minimal an
|
|
- stelle sicher, dass die neue Struktur im Build korrekt und eindeutig referenziert wird
|
|
|
|
Strikte Include-/CMake-Regeln:
|
|
- bevorzuge zielbezogene Include-Pfade mit `target_include_directories(...)`
|
|
- vermeide globale `include_directories(...)`, außer wenn das bestehende Buildsystem es an genau dieser Stelle zwingend verlangt
|
|
- füge nicht gleichzeitig alte und neue Stub-Verzeichnisse in Include-Pfade ein
|
|
- keine Workarounds durch künstliche Suchreihenfolgen
|
|
- keine Pfadverdopplungen
|
|
- keine implizite Altpfad-Kompatibilität
|
|
- nur direkt betroffene Build-Skripte ändern
|
|
|
|
Validierung:
|
|
- nutze /workspace/qt-migration-legatus/qt6-after/qt6-migrated-legatus/docker_build.sh als Validierungsweg
|
|
- passe das Script nur an, wenn für diese Aufgabe zwingend nötig
|
|
- führe mindestens Configure + Build im Docker-Kontext aus
|
|
- prüfe, dass die Builds die Dateien tatsächlich aus `forward-declarations` konsumieren
|
|
- prüfe, dass kein Build-Erfolg mehr von den alten Pfaden abhängt
|
|
- falls sinnvoll, nutze gezielte Target-Builds zusätzlich zur Gesamtvalidierung
|
|
|
|
Erfolgskriterien:
|
|
- die betroffenen Stub-/Forward-Declaration-Dateien wurden physisch nach
|
|
- /workspace/qt-migration-legatus/qt6-after/qt6-migrated-legatus/forward-declarations
|
|
verschoben
|
|
- die alten Stub-Dateien liegen nicht mehr an den bisherigen Pfaden
|
|
- Includes und CMake-Skripte sind minimal angepasst
|
|
- der Build referenziert deterministisch die neue Struktur
|
|
- keine Wrapper-/Redirect-/Kompatibilitätsheader
|
|
- keine Duplikate
|
|
- keine unnötigen Moduländerungen
|
|
- keine vorgetäuschte Validierung
|
|
|
|
Wenn etwas nicht sauber möglich ist:
|
|
- nicht mit Wrappern oder Kopien ausweichen
|
|
- nicht stillschweigend beide Strukturen parallel behalten
|
|
- als teilweise validiert oder blockiert melden
|
|
- exakten technischen Blocker benennen
|
|
|
|
Abschlussbericht nur kurz:
|
|
- validiert, teilweise validiert oder blockiert
|
|
- physisch verschobene Dateien
|
|
- geänderte Include-Stellen
|
|
- geänderte CMake-Dateien
|
|
- exakte Docker-Kommandos
|
|
- verbleibende Blocker oder Risiken
|
|
```
|