qt6-migration-pipeline/prompts/codegen-grantlee5-migration-to-ktexttemplate.prompt.md

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.