This commit is contained in:
77 files changed
-47703
No files matched your search
@@ -1,179 +0,0 @@
|
||||
Du arbeitest in einem bestehenden Legacy-Repository 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.
|
||||
Reference in new issue
Block a user