179 lines
6.6 KiB
Markdown
179 lines
6.6 KiB
Markdown
Du arbeitest in einem bestehenden Legacy-Repository ./qt-migration-legatus/qt5-before/qt5-legatus-legacy und sollst eine risikoarme Migration des Codegenerators vorbereiten und umsetzen.
|
|
|
|
## Ziel
|
|
Das Projekt verwendet aktuell ein eigenes Codegen-Tool auf Basis von Grantlee5, um aus Service-XML verschiedene Artefakte zu erzeugen, darunter:
|
|
- `.idl`
|
|
- `.h`
|
|
- `.cpp`
|
|
- `.sql`
|
|
- kopierte `.xml`
|
|
|
|
Das Legacy-Projekt basiert auf Qt5.
|
|
Das Ziel ist Qt6.
|
|
Grantlee5 soll durch KDE KTextTemplate ersetzt werden.
|
|
|
|
Du sollst den bestehenden Generator analysieren, einen minimal-invasiven Migrationspfad entwerfen und den Generator so portieren oder neu implementieren, dass er unter Qt6 mit KTextTemplate funktioniert, ohne die bestehende Build-Integration unnötig zu brechen.
|
|
|
|
## Wichtiger Kontext
|
|
Aus `MacroCodeGenIdl.cmake` geht hervor:
|
|
- Es gibt zentrale Codegen-Actions wie:
|
|
- `DDS_TOPICS`
|
|
- `DATABASE`
|
|
- `DATABASE_SERVER`
|
|
- `SQL`
|
|
- `dao`
|
|
- Aus XML werden je nach Action mehrere Ausgabedateien erzeugt.
|
|
- Die CMake-Makros erwarten bestimmte Dateinamen und Ausgabepfade.
|
|
- Templates liegen unter `Lts/Common/CodeGen/*.grantlee`.
|
|
- `CODEGEN_TOPIC_TYPEDEFS(...)` verwendet separat ein Python-Skript (`codegen_simple.py`).
|
|
- Die `.idl`-Dateien sind hier generierte Textartefakte; sie sind nicht automatisch als C++ zu behandeln.
|
|
- C++-Header/Implementierungen, SQL und XML müssen im Generator als unterschiedliche Artefakttypen sauber behandelt werden.
|
|
|
|
## Deine Aufgaben
|
|
|
|
### 1) Bestehendes System analysieren
|
|
Untersuche zuerst vollständig:
|
|
- das aktuelle `codegen`-Tool
|
|
- alle Aufrufstellen der Codegen-Actions
|
|
- alle `*.grantlee`-Templates
|
|
- XML-Parsing und Context-Aufbau
|
|
- eventuelle benutzerdefinierte Grantlee-Filter, Tags, Helper, Loader oder Include-Mechanismen
|
|
- die CMake-Integration rund um `MacroCodeGenIdl.cmake`
|
|
|
|
Suche insbesondere nach:
|
|
- `codegen`
|
|
- `Grantlee`
|
|
- `*.grantlee`
|
|
- `DDS_TOPICS`
|
|
- `DATABASE`
|
|
- `DATABASE_SERVER`
|
|
- `dao`
|
|
- `SQL`
|
|
- `codegen_simple.py`
|
|
|
|
### 2) Zielarchitektur ableiten
|
|
Leite auf Basis des Ist-Zustands eine Zielarchitektur ab für einen Qt6-basierten Generator mit KTextTemplate:
|
|
- Ein-/Ausgabe-Modell
|
|
- Zuordnung Action → Template(s) → Output-Dateien
|
|
- XML → internes Datenmodell → Template-Context
|
|
- Include-/Partial-Strategie
|
|
- Fehlerbehandlung
|
|
- deterministische Dateigenerierung
|
|
- Encoding/Newline-Verhalten
|
|
- Logging/Diagnostik bei Template-Fehlern
|
|
|
|
### 3) Migration implementieren
|
|
Setze die Migration minimal-invasiv um:
|
|
- Qt6 statt Qt5
|
|
- KTextTemplate statt Grantlee5
|
|
- Bestehende Action-Namen und CMake-Aufrufmuster möglichst beibehalten
|
|
- Bestehende Dateinamen und Output-Orte beibehalten
|
|
- bestehende Template-Logik so weit wie möglich kompatibel halten
|
|
|
|
Wenn direkte Kompatibilität nicht möglich ist:
|
|
- implementiere eine dünne Adapter-/Kompatibilitätsschicht
|
|
- oder migriere betroffene Templates kontrolliert und dokumentiert
|
|
|
|
### 4) Build-System anpassen
|
|
Passe CMake so an, dass:
|
|
- der neue Generator im Qt6-Setup gebaut wird
|
|
- die bestehenden Makros nach Möglichkeit weiter funktionieren
|
|
- Incremental Builds nicht unnötig verschlechtert werden
|
|
- Abhängigkeiten auf Templates und XML sauber erhalten bleiben
|
|
|
|
### 5) Dokumentation ergänzen
|
|
Erstelle Migrationsnotizen in Markdown:
|
|
- bisherige Architektur
|
|
- neue Architektur
|
|
- Unterschiede Grantlee5 vs. KTextTemplate
|
|
- notwendige Template-Anpassungen
|
|
- bekannte Inkompatibilitäten
|
|
- offene Risiken
|
|
- Follow-up-Empfehlungen
|
|
|
|
## Harte Randbedingungen
|
|
- Keine unnötige Komplett-Neuschreibung.
|
|
- Keine großflächigen Refactorings außerhalb des Codegen-Bereichs.
|
|
- Keine Änderung der fachlichen XML-Semantik ohne klare Notwendigkeit.
|
|
- Keine Änderung der erwarteten Output-Dateinamen ohne sehr gute Begründung.
|
|
- Keine Änderung der öffentlichen CMake-Makro-Schnittstellen, wenn vermeidbar.
|
|
- Python-basierten Teil (`codegen_simple.py`) nur dann anfassen, wenn er für Qt6-/Build-Kompatibilität relevant ist.
|
|
|
|
## Erwartetes Vorgehen
|
|
1. Zuerst analysieren, nicht blind umschreiben.
|
|
2. Dann eine kurze Migrationsstrategie formulieren.
|
|
3. Danach gezielte Codeänderungen durchführen.
|
|
4. Änderungen klein und reviewbar halten.
|
|
5. Wenn möglich vorhandene Tests/Build-Ziele nutzen oder ergänzen.
|
|
6. Falls keine Tests existieren, mindestens Plausibilitätschecks für die Generierung einbauen.
|
|
|
|
## Explizit zu prüfende Risiken
|
|
Prüfe und dokumentiere ausdrücklich:
|
|
- benutzerdefinierte Grantlee-Filter/Tags
|
|
- Unterschiede bei Schleifen, Includes, Escaping und Kontextauflösung
|
|
- Mehrfachgenerierung pro Action
|
|
- Pfad- und Dateinamenskonventionen
|
|
- Reihenfolge/Stabilität generierter Inhalte
|
|
- UTF-8 / Zeilenenden
|
|
- Verhalten bei fehlenden XML-Feldern
|
|
- Fehlerdiagnose bei Template-Rendering-Problemen
|
|
- CMake-Dependencies und Rebuild-Verhalten
|
|
|
|
## Akzeptanzkriterien
|
|
Die Aufgabe ist erst dann fertig, wenn mindestens Folgendes erfüllt ist:
|
|
|
|
1. Ein Qt6-basierter Generator existiert oder der alte Generator ist erfolgreich auf Qt6 portiert.
|
|
2. Grantlee5-Abhängigkeit ist im migrierten Pfad entfernt oder isoliert ersetzt.
|
|
3. KTextTemplate wird für das Rendering verwendet.
|
|
4. Die bisherigen zentralen Actions sind weiterhin abbildbar:
|
|
- `DDS_TOPICS`
|
|
- `DATABASE`
|
|
- `DATABASE_SERVER`
|
|
- `SQL`
|
|
- `dao`
|
|
5. Die generierten Output-Dateien bleiben in Namen und Verzeichnisstruktur kompatibel, soweit technisch möglich.
|
|
6. Die CMake-Integration funktioniert weiterhin mit den vorhandenen Makros oder mit minimalen kompatiblen Anpassungen.
|
|
7. Die Migration ist dokumentiert.
|
|
8. Bekannte Inkompatibilitäten und Restarbeiten sind klar benannt.
|
|
|
|
## Definition of Done
|
|
Am Ende liefere bitte:
|
|
|
|
1. **Kurze Architekturzusammenfassung**
|
|
- Alt
|
|
- Neu
|
|
- wichtigste Unterschiede
|
|
|
|
2. **Umgesetzte Migrationsentscheidungen**
|
|
- warum KTextTemplate so eingebunden wurde
|
|
- ob Adapter oder direkte Template-Migration gewählt wurde
|
|
- warum
|
|
|
|
3. **Liste aller geänderten Dateien**
|
|
|
|
4. **Konkrete Codeänderungen**
|
|
- inklusive CMake-Anpassungen
|
|
- Generator-Code
|
|
- Template-Anpassungen
|
|
- Doku
|
|
|
|
5. **Validierung**
|
|
- was gebaut/getestet wurde
|
|
- was nur statisch geprüft wurde
|
|
- was noch offen ist
|
|
|
|
6. **Offene Risiken / Follow-ups**
|
|
|
|
## Bevorzugte Ergebnisqualität
|
|
Bevorzuge eine inkrementelle, robuste Migration über eine elegante, aber riskante Neuentwicklung.
|
|
Wenn mehrere Wege möglich sind, entscheide dich für den mit:
|
|
- geringstem Integrationsrisiko
|
|
- geringster Build-Störung
|
|
- bester Nachvollziehbarkeit im Review
|
|
|
|
Wenn Annahmen notwendig sind:
|
|
- triff sie explizit,
|
|
- dokumentiere sie,
|
|
- und halte Änderungen reversibel.
|
|
|
|
Bitte arbeite repository-basiert und leite Entscheidungen aus dem tatsächlich vorhandenen Code ab, nicht aus allgemeinen Annahmen über Grantlee oder KTextTemplate. |