From 08097c6f4f1ad6d8ab9c23776864c6334b601cd2 Mon Sep 17 00:00:00 2001 From: twi-devel Date: Fri, 4 Sep 2026 21:34:36 +0200 Subject: [PATCH] Moves prompts somewhere else --- ...tlee5-migration-to-ktexttemplate.prompt.md | 179 ++++++++++++++ prompts/combined-migration-compact.prompt.md | 167 +++++++++++++ prompts/commit-policy.prompt.md | 94 ++++++++ ...-qt6-migration-after-resume-loop.prompt.md | 64 +++++ ...oktexttemplate-integration-check.prompt.md | 166 +++++++++++++ ...e-parser-toktexttemplate-porting.prompt.md | 39 +++ .../legacyrti_to_rti77_migration_prompt.md | 228 ++++++++++++++++++ 7 files changed, 937 insertions(+) create mode 100644 prompts/codegen-grantlee5-migration-to-ktexttemplate.prompt.md create mode 100644 prompts/combined-migration-compact.prompt.md create mode 100644 prompts/commit-policy.prompt.md create mode 100644 prompts/continue-qt6-migration-after-resume-loop.prompt.md create mode 100644 prompts/grantlee-parser-toktexttemplate-integration-check.prompt.md create mode 100644 prompts/grantlee-parser-toktexttemplate-porting.prompt.md create mode 100644 prompts/legacyrti_to_rti77_migration_prompt.md diff --git a/prompts/codegen-grantlee5-migration-to-ktexttemplate.prompt.md b/prompts/codegen-grantlee5-migration-to-ktexttemplate.prompt.md new file mode 100644 index 000000000..26f819a3a --- /dev/null +++ b/prompts/codegen-grantlee5-migration-to-ktexttemplate.prompt.md @@ -0,0 +1,179 @@ +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. \ No newline at end of file diff --git a/prompts/combined-migration-compact.prompt.md b/prompts/combined-migration-compact.prompt.md new file mode 100644 index 000000000..8e3b491ef --- /dev/null +++ b/prompts/combined-migration-compact.prompt.md @@ -0,0 +1,167 @@ +# GitHub Copilot Instructions: Qt5/C++11 to Qt6/C++17 Migration + +## Mission +Migrate the legacy Qt5/C++11 desktop application to Qt6/C++17, preserve behavior unless change is strictly required, and validate the result completely in the repository’s Docker-based CI workflow. + +## Operating Mode +- Work autonomously from analysis through validation. +- Do not stop after editing code. +- Continue until configure, build, tests, and policy checks have been attempted in Docker. +- Do not ask for confirmation during normal implementation. +- Stop early only if required source material is missing, the task is impossible, or a destructive action would be required. + +## Boundaries +- Read the legacy project from `./qt-migration-legatus/qt5-before/qt5-legatus-legacy`. +- Write the migrated project to `./qt-migration-legatus/qt6-after/qt6-migrated-legatus`. +- Do not modify the legacy source tree in place. +- Limit changes to the target tree and only the CI/build/test files needed to support migration and validation. + +## Main Migration Targets +- Upgrade Qt5 to Qt6. +- Upgrade C++11/14/17 code to C++17. +- Keep Qt Core, Gui, and Widgets explicitly linked. +- Replace `QRegExp` with `QRegularExpression`. +- Replace `QDesktopWidget` and `QApplication::desktop()` with `QScreen`-based Qt6 APIs. +- Remove legacy `QTextCodec` usage and adopt Qt6-safe text handling. +- Replace old `SIGNAL`/`SLOT` syntax with function-pointer connect syntax. +- Replace `0`/`NULL` pointer literals with `nullptr`. +- Preserve `.ui` and `.qrc` integration. +- Preserve behavior unless Qt6 compatibility requires adaptation. + +## C++17 Modernization Rules +- Preserve semantics first; modernize second. +- Use `auto` when the type is obvious; avoid it when it hides important type information. +- Prefer structured bindings where clearer. +- Replace raw owning pointers/manual `delete` with RAII, usually `std::unique_ptr`. +- Use `std::make_unique` / `std::make_shared`; use `std::shared_ptr` only for real shared ownership. +- Use `std::string_view` only when lifetime safety is clear. +- Prefer `std::span` for non-owning contiguous data; use `std::mdspan` only when multidimensional access clearly benefits. +- Prefer `.contains()` over `find(...) != end()` where available. +- Prefer algorithms and ranges over manual loops when readability improves. +- Use `[[nodiscard]]` when ignoring a result is likely a bug. +- Prefer early returns over deeply nested control flow. +- Use `std::optional` monadic operations (`and_then`, `transform`, `or_else`) when clearer. +- Prefer `constexpr`, `if constexpr`, concepts, and `requires` over legacy `std::enable_if`/SFINAE where practical. +- Add `noexcept`, `override`, `final`, `= default`, and `= delete` where correct and useful. +- Prefer `enum class` over unscoped enums where practical. +- Prefer `std::print` / `std::println` when supported by the toolchain. +- Prefer typed `std::chrono` durations and `std::jthread` where appropriate. + +## Safety Rules +- Do not change business logic unless explicitly requested or required for Qt6 compatibility. +- Do not introduce unsupported Qt6/C++17 features. +- Do not silently change ABI, ownership, lifetime, exception behavior, performance, UI behavior, or event ordering. +- Do not worsen readability for the sake of modernization. +- Do not refactor code. +- Avoid dangling references, dangling `std::string_view`, and ownership ambiguity. +- Keep includes minimal and preserve repository-local formatting/style. +- no code cleanup +- no renaming +- no extraction of functions/classes +- no restructuring of logic +- no stylistic rewrites +- no dependency modernization +- no opportunistic improvements +- no behavior changes beyond path/build necessity + +## Tests +- For every code change inside a method, add at least three tests covering the changed behavior. +- Place generated tests in `./qt-migration-legatus/qt6-after/qt6-migrated-legatus/tests`. +- Use policy-compatible test filenames such as: + - `test_.cpp` + - `_test.cpp` + - `test.cpp` + - `gtest.cpp` + as searched for in `./qt-migration-legatus/ci/check_pr_policies.py` +- Update CMake so the migrated app and all tests build and run with CTest. +- Ensure all tests are registered with CTest. + +## Docker-First Validation +Use `lifemaps/ci-cpp:latest` as the authoritative environment. Do not substitute host tools for missing container tools. Treat `./qt-migration-legatus/ci/Dockerfile.ci` as the source of truth for CI dependencies. + +### Required validation sequence +1. Configure in Docker +2. Build in Docker +3. Run tests in Docker +4. If tests pass, run `python3 ci/check_pr_policies.py` in Docker + +### Recommended commands +- Configure: + `cmake -S ./qt-migration-legatus/qt6-after/qt6-migrated-legatus -B build -G Ninja -DCMAKE_BUILD_TYPE=Debug` +- Build: + `cmake --build build --parallel` +- Test: + `ctest --test-dir build --output-on-failure` +- Policy: + `python3 ./qt-migration-legatus/ci/check_pr_policies.py` + +Adapt paths/flags only if repository inspection proves they must differ. + +## Missing-Tool Remediation +If Docker validation fails because a required tool/package is missing: +- identify the exact missing dependency +- update `./qt-migration-legatus/ci/Dockerfile.ci` minimally +- rebuild `lifemaps/ci-cpp:latest` +- rerun the full validation sequence + +Continue until: +- validation succeeds, or +- the next blocker is a genuine project/code issue + +## Failure Classification +Environment failures: +- command not found +- missing compiler/toolchain utility +- missing Qt dev package +- missing CMake/Ninja/CTest support tool +- missing dependency required by `./qt-migration-legatus/ci/check_pr_policies.py` + +Project failures: +- compile errors +- linker errors +- failing tests +- formatting/policy failures caused by migration changes + +## Policy Awareness +- `./qt-migration-legatus/ci/check_pr_policies.py` checks formatting for changed C/C++ files, expects related tests, and verifies commit-signature conditions in its diff range. +- Ensure Docker validation runs with mounted workspace and git metadata available. +- Do not claim success unless the policy script passes. + +## Execution Plan +1. Inspect `./qt-migration-legatus/` and the target tree. +2. Identify Qt5 and legacy C++ constructs to migrate. +3. Migrate incrementally in `qt6-after/qt6-migrated-legatus`. +4. Add/update tests with each behavior-relevant change. +5. Update CMake/test registration. +6. Validate in Docker. +7. If missing dependencies are found, update `./qt-migration-legatus/ci/Dockerfile.ci`, rebuild, and rerun. +8. Repeat until success or a real project defect remains. + +## Reporting +Group change explanations by: +- CMake / build-system migration +- Qt API replacements +- C++ modernization +- UI/resource preservation +- tests added +- `./qt-migration-legatus/ci/Dockerfile.ci` / container updates + +Also provide a concise changed-files summary. + +## Completion Criteria +Success requires: +- migrated project exists under `./qt-migration-legatus/qt6-after/qt6-migrated-legatus` +- configure succeeds in Docker +- build succeeds in Docker +- tests succeed in Docker +- `python3 ci/check_pr_policies.py` succeeds in Docker after tests pass + +## Final Response +- State whether migration is fully validated or which blocker remains. +- List the exact Docker commands used for image rebuild, configure, build, test, and policy check. +- For every failed attempt, include: + - exact command + - key error + - environment vs project classification + - fix applied +- End with a short summary of any remaining blocker. \ No newline at end of file diff --git a/prompts/commit-policy.prompt.md b/prompts/commit-policy.prompt.md new file mode 100644 index 000000000..f4175a3fa --- /dev/null +++ b/prompts/commit-policy.prompt.md @@ -0,0 +1,94 @@ +Task: Work in this workspace with multiple Git repositories. Before making any changes, determine the correct target repository for each file based strictly on its path, then perform changes, validation, and commits only in the matching repository. + +Repository layout detected under `./`: +- `./.git` +- `./qt-migration-legatus/.git` +- `./qt-migration-legatus/qt5-before/qt5-legatus-legacy/.git` +- `./jenkins-ci-rme/.git` +- `./rpmbuild/.git` + +Critical constraint: +There are multiple Git repositories in this workspace. You must first determine for each planned change which repository root it belongs to, based strictly on the file path. Each change must be made and committed in the matching Git repository only. + +Repository mapping in this workspace: +- files under `./qt-migration-legatus/` -> commit only in `./qt-migration-legatus` +- files under `./jenkins-ci-rme/` -> commit only in `./jenkins-ci-rme` +- files under `./rpmbuild/` -> commit only in `./rpmbuild` +- files at workspace root `./...` not inside one of the sub-repositories -> commit only in `./` + +Rules derived from this: +- Never commit a file from one repository into another repository. +- Never use `./` as the commit target for files that belong to `./qt-migration-legatus`, `./qt-migration-legatus/qt5-before/qt5-legatus-legacy/`, `./jenkins-ci-rme`, or `./rpmbuild`. +- Never use a sub-repository as the commit target for files that belong to workspace root `./`. +- Before changing any file, determine its owning repository from its path and show that mapping explicitly. +- If a planned change spans multiple repositories, handle each repository separately. +- Create separate status checks, validation runs, and commits per repository. +- If repository ownership for any file is ambiguous, stop and report it instead of guessing. + +Signed commit requirement: +- Only signed commits are allowed. +- Do not create unsigned commits. +- Before committing in any repository, verify that commit signing is configured and usable for that repository context. +- Check at minimum: + - `git config --global --list` + - `cd && git config --get commit.gpgsign` + - `cd && git config --get user.signingkey` + - If repository-local signing settings exist, inspect and respect them as well. + - If signing is required but not configured or not functional, stop and report the exact reason. + - When committing, create a signed commit only. + - After committing, show evidence that the created commit is signed by running: + - `cd && git log -1 --show-signature` + +Required checks before making any changes: +1. `ssh -T devel` +2. `git config --global --list` +3. `find . -type d -name .git -prune | sort` + +Then, for each repository that will actually be modified, run these checks in that repository before making changes: +1. `cd && pwd` +2. `cd && git rev-parse --is-inside-work-tree` +3. `cd && git rev-parse --show-toplevel` +4. `cd && git remote -v` +5. `cd && git branch --show-current` +6. `cd && git status --short` +7. `cd && git config --get remote.origin.url` + +Repository-selection procedure: +- List every file you plan to modify. +- For each file, map it to exactly one repository root using the path rules above. +- Group planned changes by repository before making any edits. +- Show the grouping explicitly before changing files. + +Hard rules: +- Do not guess. Do not silently switch repositories. +- Do not modify files before their owning repository has been identified and checked. +- If any repository check fails: stop for that repository and report the exact reason. +- If a file would be committed from the wrong repository: stop. +- If `git rev-parse --show-toplevel` does not match the expected repository root for a file: stop. +- If there is no sensible remote or no plausible write access for a repository: stop for that repository. +- Do not combine changes from different repositories into one commit. +- Do not skip validation for any repository being changed. + +Validation: +- Run all relevant tests for the changes in each affected repository. +- Run all locally checkable check-in policies for each affected repository. +- Keep validation scoped to the repository being changed. +- If tests or policies fail, or cannot be executed, do not commit in that repository. + +Automatic commit: +- If all checks, tests, and check-in policies pass for a repository, commit automatically in that repository. +- Before committing, show: `cd && git status --short` +- After committing, output: + - `cd && git rev-parse HEAD` + - current branch + - remote URL + - changed files + +Output format: +- Show every global check command with raw output. +- Show the discovered `.git` directories. +- Show the list of planned changed files and the repository mapping for each file. +- Show all per-repository check commands with raw output. +- Show all test and policy results per repository. +- On failure in any repository: stop committing in that repository, do not guess, and report exact reasons. +- On success: commit separately per repository and print commit hash, branch, remote, and changed files for each commit. \ No newline at end of file diff --git a/prompts/continue-qt6-migration-after-resume-loop.prompt.md b/prompts/continue-qt6-migration-after-resume-loop.prompt.md new file mode 100644 index 000000000..2fabc261f --- /dev/null +++ b/prompts/continue-qt6-migration-after-resume-loop.prompt.md @@ -0,0 +1,64 @@ +# Continue Qt6 migration after broken resume + +Setze die Qt6-Migration fort. + +## Kontext +Die vorherige Copilot-CLI-Session wurde nach einem `pkill` resumed und ist in einer Endlosschleife hängen geblieben. Sie hat wiederholt nur den Arbeitsstand gelesen/zusammengefasst und nicht weiter implementiert. Dieses Verhalten darf sich nicht wiederholen. + +Ein partieller Zwischenstand ist in `./MIGRATION_STATUS.md` gesichert. + +Unter `./.github/prompts/` liegen bestehende Prompt-Dateien, die die ursprüngliche Migrationsaufgabe beschreiben. Diese Arbeit ist bereits in Bearbeitung und soll fortgesetzt, nicht neu aufgesetzt werden. + +## Verzeichnisrollen +- `./qt-migration-legatus/qt6-after/qt6-migrated-legatus/` + - primärer Arbeitsort + - hier werden die Migrationsergebnisse umgesetzt +- `./qt-migration-legatus/qt5-before/qt5-legatus-legacy/` + - **read-only** + - nur als Referenz für Vergleich, Verhalten und Portierung nutzen + - **keine Änderungen** +- `./external/` + - externe Abhängigkeiten + - nur anfassen, wenn es für einen echten Qt6-Build-/Compile-Blocker zwingend nötig ist + +## Strikte Arbeitsregeln +1. `./MIGRATION_STATUS.md` genau einmal am Anfang lesen. +2. Die Prompt-Dateien unter `./.github/prompts/` genau einmal als Kontext lesen. +3. Danach den tatsächlichen Codezustand prüfen. +4. Nicht in erneute Statusanalyse oder Wiederholungszusammenfassungen verfallen. +5. Nicht mehrfach dieselben Statusdateien oder Prompts lesen. +6. Der aktuelle Codezustand hat Vorrang vor älteren Notizen. +7. Wenn Notizen und Code voneinander abweichen, dem Code folgen. +8. `./MIGRATION_STATUS.md` nur am Ende aktualisieren. + +## Verpflichtende Arbeitsreihenfolge +1. `./MIGRATION_STATUS.md` einmal lesen +2. die vorhandenen Prompts einmal lesen +3. den Ist-Zustand in `./qt-migration-legatus/qt6-after/qt6-migrated-legatus/` prüfen +4. die nächsten 1-3 konkreten Qt6-Migrationsprobleme identifizieren +5. diese Probleme direkt im Code beheben +6. bei Bedarf gezielt mit `./qt-migration-legatus/qt5-before/qt5-legatus-legacy/` vergleichen +7. `./external/` nur bei echtem Blocker prüfen +8. am Ende `./MIGRATION_STATUS.md` aktualisieren + +## Was nicht passieren darf +- keine Endlosschleife aus Lesen und Zusammenfassen +- keine lange Bestandsaufnahme +- kein reines Re-Planning ohne Codeänderungen +- keine Änderungen im Read-only-Referenzbaum +- keine unnötigen Änderungen unter `./external/` + +## Priorität +1. Build-/Compile-Blocker im Zielcode beheben +2. veraltete Qt5-APIs im Zielcode auf Qt6 umstellen +3. Signal/Slot-, Header-, Modul- und CMake-Anpassungen umsetzen +4. danach Statusdatei aktualisieren + +## Ausgabeformat +Nach jeder relevanten Änderung kurz ausgeben: +- Geändert: +- Grund: +- Nächster Schritt: + +## Ziel +Nicht den Stand verwalten, sondern die Qt6-Migration konkret in `./qt-migration-legatus/qt6-after/qt6-migrated-legatus/` weiter implementieren. \ No newline at end of file diff --git a/prompts/grantlee-parser-toktexttemplate-integration-check.prompt.md b/prompts/grantlee-parser-toktexttemplate-integration-check.prompt.md new file mode 100644 index 000000000..45ec838c5 --- /dev/null +++ b/prompts/grantlee-parser-toktexttemplate-integration-check.prompt.md @@ -0,0 +1,166 @@ +Verify the build-system integration of the already ported Qt6/KTextTemplate parser and ensure it correctly replaces the legacy Qt5/Grantlee5 parser behavior in the surrounding Qt5 → Qt6 migration. + +## Scope +The parser port itself is already complete. This task is strictly about build integration verification and correction, with special focus on: +- original invocation logic in the Qt5 legacy build +- correct port of that invocation logic to the Qt6 build +- custom command / custom target wiring +- generated-file placement in the build tree +- downstream consumption of generated C++ files by Qt6 targets +- final Qt6 Docker build validation +- clean and incremental build correctness + +## Paths to inspect + +### Legacy Qt5 side +- `./qt-migration-legatus/qt5-before/qt5-legatus-legacy` +- `./qt-migration-legatus/qt5-before/qt5-legatus-legacy/Lts/Common/CodeGen` + +### Qt6 migrated side +- `./qt-migration-legatus/qt6-after/qt6-migrated-legatus` +- `./qt-migration-legatus/qt6-after/qt6-migrated-legatus/Lts/Common/CodeGen` + +### CMake / macro files +- `./qt-migration-legatus/qt5-before/qt5-legacy-legatus/cmake/MacroCodeGenIdl.cmake` +- `./qt-migration-legatus/qt6-after/qt6-migrated-legatus/cmake/MacroCodeGenIdl.cmake` + +### Docker build entry +- `./app/Dockerfile` + +### External dependencies +- `./external` +- especially ensure RTI `7.7.arcgis` from `./external` is mapped into the container correctly when needed + +## Required investigation + +### 1. Reconstruct the original Qt5 invocation logic +Analyze the legacy Qt5/Grantlee5 integration and determine: +- which CMake functions/macros trigger parser execution +- whether parser execution happens via `add_custom_command`, `add_custom_target`, helper macros, or another mechanism +- the exact dependency chain that causes parser execution +- when parser execution happens relative to target compilation +- which input files trigger regeneration +- which output files are declared or assumed +- how generated `.cpp` and header files are handed to downstream targets +- whether outputs are placed in source tree or build tree +- whether the original flow depends on implicit behavior that must now be made explicit + +### 2. Verify the Qt6 port of that logic +Analyze the Qt6/KTextTemplate integration and verify whether the original invocation logic was ported correctly into: +`./qt-migration-legatus/qt6-after/qt6-migrated-legatus` + +Check specifically: +- whether equivalent macro/function call sites exist +- whether the parser executable is invoked from the correct custom command or target +- whether invocation order matches the legacy build intent +- whether any function call logic was dropped, reordered, or incompletely migrated +- whether downstream Qt6 targets depend on generation strongly enough to avoid race/order issues + +### 3. Check CMake generated-file semantics +Inspect and fix, where necessary: +- `add_custom_command(OUTPUT ...)` +- `BYPRODUCTS` +- `DEPENDS` +- `MAIN_DEPENDENCY` +- `WORKING_DIRECTORY` +- `COMMAND` +- `VERBATIM` +- `target_sources(...)` +- source properties such as `GENERATED` +- include directory wiring for generated headers +- target-level dependencies via `add_dependencies(...)` +- whether generated files are attached to the correct consuming target +- whether output paths use `${CMAKE_CURRENT_BINARY_DIR}` / build-tree locations instead of stale source-tree paths + +### 4. Verify output placement +Confirm that generated files are emitted to the correct build-tree location expected by the Qt6 build. +Check for: +- stale Qt5-era output directories +- source-tree output instead of build-tree output +- mismatches between actual output location and `target_sources(...)` paths +- mismatches between parser CLI output arguments and CMake-declared outputs +- missing directory creation for generated output folders + +### 5. Validate final Docker-based Qt6 builds +The final verification must execute the Qt6 build inside the Docker container defined by: +`./app/Dockerfile` + +There are two required build variants and both must work: +- `BUILD_RTI=ON` +- `BUILD_RTI=OFF` + +Validate both variants end-to-end: +- configure +- parser generation +- compilation +- generated-file discovery by consuming Qt6 targets + +### 6. Validate external dependency mapping +External dependencies live in: +`./external` + +Check and fix, if necessary: +- container mapping of `./external` +- availability of required external dependencies during configure/build +- especially correct container mapping and usability of RTI `7.7.arcgis` +- any CMake path assumptions related to mounted external dependencies +- whether `BUILD_RTI=ON` correctly picks up mapped RTI dependencies +- whether `BUILD_RTI=OFF` correctly avoids requiring RTI at configure/build time + +### 7. Verify build correctness +Validate: +- clean build behavior +- incremental build behavior +- regeneration when input templates or related inputs change +- no missing dependency edges +- no accidental dependence on file timestamps outside declared CMake dependencies +- no ordering bugs hidden by already-generated files in developer workspaces + +## Fixes to implement if issues are found +Implement minimal, reviewable fixes for: +- incorrect invocation timing +- incomplete migration of function/macro call logic +- missing `DEPENDS`, `BYPRODUCTS`, or `GENERATED` declarations +- incorrect output directories +- generated files not added to consuming targets +- generated headers not discoverable through include paths +- parser invocation not happening before compilation +- incremental rebuilds not retriggering generation when inputs change +- incorrect handling of `BUILD_RTI=ON` / `BUILD_RTI=OFF` +- incorrect external dependency mapping in Docker/container build flow + +## Acceptance criteria +The task is complete only if all of the following are true: + +1. The original Qt5 legacy parser invocation logic has been analyzed and reconstructed. +2. It has been verified whether that logic was ported correctly to the Qt6/KTextTemplate integration. +3. The Qt6 parser is invoked automatically at the correct stage of the build. +4. Generated `.cpp` files and related headers are emitted into the correct build-tree location. +5. Qt6 consuming targets reference the generated files from the actual generated paths. +6. The final Qt6 build is executed in the Docker environment defined by `./app/Dockerfile`. +7. Both build variants succeed: + - `BUILD_RTI=ON` + - `BUILD_RTI=OFF` +8. External dependencies from `./external` are handled correctly in the container build, especially RTI `7.7.arcgis`. +9. Relevant macro/CMake wiring is correct, explicit, and robust. +10. Clean and incremental builds behave correctly. +11. Any integration bugs found were fixed with minimal changes. +12. A concise final summary is provided covering: + - original Qt5 invocation flow + - Qt6 invocation flow + - whether the ported invocation logic matches + - output locations + - Docker validation results + - `BUILD_RTI=ON` result + - `BUILD_RTI=OFF` result + - external dependency mapping result + - files changed + - issues found and fixed + - remaining risks or assumptions + +## Constraints +- Do not re-port parser functionality unless a very small parser-side change is strictly necessary for build integration. +- Focus on build-system correctness, invocation timing, generated-file registration, output placement, Docker validation, and RTI/non-RTI build behavior. +- Preserve already completed Qt6 migration work. +- Prefer explicit and deterministic CMake wiring over implicit behavior. + diff --git a/prompts/grantlee-parser-toktexttemplate-porting.prompt.md b/prompts/grantlee-parser-toktexttemplate-porting.prompt.md new file mode 100644 index 000000000..43b8e2f5e --- /dev/null +++ b/prompts/grantlee-parser-toktexttemplate-porting.prompt.md @@ -0,0 +1,39 @@ +Implement a Qt6 replacement for the legacy Qt5/Grantlee5 CodeGen parser and integrate it into the Qt6 build flow. + +Context: +- Legacy parser A (Qt5 + Grantlee5): + `./qt-migration-legatus/qt5-before/qt5-legatus-legacy/Lts/Common/CodeGen` +- Replacement parser B (Qt6 + KTextTemplate): + `./qt-migration-legatus/qt6-after/qt6-migrated-legatus/Lts/Common/CodeGen` +- Docker build entry: + `./app/Dockerfile` +- Relevant macros: + - `./qt-migration-legatus/qt5-before/qt5-legacy-legatus/cmake/MacroCodeGenIdl.cmake` + - `./qt-migration-legatus/qt6-after/qt6-migrated-legatus/cmake/MacroCodeGenIdl.cmake` + +Goals: +1. Analyze how A is built and invoked in the Qt5 flow. +2. Make B build reproducibly via `./app/Dockerfile` with Qt6 + KTextTemplate. +3. Find all relevant `*grantlee*` input files and test B against all of them. +4. Fix/extend B only as needed to support real repository inputs. +5. Integrate B into the Qt6 codegen/build flow based on how A is invoked. +6. Update the relevant CMake/macro wiring. +7. Preserve existing Qt6 migration work. + +Requirements: +- Use Docker for building B. +- Use Docker to create and remove folders/files +- Inspect real call sites before changing integration. +- Keep changes small and reviewable. +- Touch Qt5-side files only if needed for analysis/comparison/minimal build clarity. +- If Grantlee behavior cannot be matched exactly in KTextTemplate, implement the best practical transitional solution and document remaining gaps. +- `./qt-migration-legatus/qt5-before/qt5-legacy-legatus` is read-only + +Done when: +- B builds successfully through `./app/Dockerfile` +- all relevant `*grantlee*` inputs were tested with B +- Qt6 build flow uses B instead of Grantlee5 dependency +- macro/CMake integration is updated +- remaining incompatibilities are documented +- provide a concise summary of changed files, test results, and open gaps +- commit and push in `./qt-migration-legatus/qt6-after/qt6-migrated-legatus` after user feedback diff --git a/prompts/legacyrti_to_rti77_migration_prompt.md b/prompts/legacyrti_to_rti77_migration_prompt.md new file mode 100644 index 000000000..785c38a37 --- /dev/null +++ b/prompts/legacyrti_to_rti77_migration_prompt.md @@ -0,0 +1,228 @@ +Verify and, if necessary, fix the build-system integration of the RTI 7.7 codegen parser in the Qt6 migration so that it correctly replaces the legacy Qt5/RTI parser integration behavior. + +## Goal + +The RTI 7.7 codegen parser port itself already exists. This task is **only** about verifying and correcting the **build-system integration** around it. + +Focus on: +- legacy Qt5 invocation behavior +- correctness of the Qt6 port of that behavior +- custom command / custom target wiring +- generated file placement +- downstream consumption by Qt6 targets +- Docker-based build validation +- clean and incremental rebuild correctness +- RTI/non-RTI build behavior +- external dependency and RTI license handling in the container build flow + +## Repository areas to inspect + +### Legacy Qt5 side +- `./qt-migration-legatus/qt5-before/qt5-legatus-legacy` + +### Qt6 migrated side +- `./qt-migration-legatus/qt6-after/qt6-migrated-legatus` + +### CMake / macro files +- `./qt-migration-legatus/qt5-before/qt5-legatus-legacy/cmake/MacroRTIDDSGen.cmake` +- `./qt-migration-legatus/qt6-after/qt6-migrated-legatus/cmake/MacroRTIDDSGen.cmake` + +### Docker build entry +- `./app/Dockerfile` + +### External dependencies +- `./external` +- expected subfolders: + - `./external/ArcGIS` + - `./external/GeographicLib` + - `./external/rti_connext_dds-7.7.0` + +### RTI license +- `./rti_license.dat` + +If `BUILD_RTI=ON` requires an RTI license, ensure the containerized build can access it correctly. + +--- + +## Required tasks + +### 1) Reconstruct the original Qt5 invocation logic +Analyze the legacy Qt5 integration and determine: + +- which CMake functions/macros trigger RTI parser execution +- whether generation is driven by `add_custom_command`, `add_custom_target`, helper macros, or other logic +- the exact dependency chain from inputs to generated outputs to consuming targets +- when generation happens relative to target compilation +- which inputs trigger regeneration +- which outputs are explicitly declared vs implicitly assumed +- how generated `.cpp` / header files are passed to downstream targets +- whether outputs go to source tree or build tree +- whether the old flow relied on implicit behavior that now must be explicit in Qt6/CMake + +### 2) Verify the Qt6 port of that invocation logic +Analyze the Qt6 migration and confirm whether the original build behavior was ported correctly into: + +- `./qt-migration-legatus/qt6-after/qt6-migrated-legatus` + +Check specifically: + +- whether equivalent macro/function call sites exist +- whether the parser executable is invoked from the correct custom command/target +- whether invocation order matches the original build intent +- whether any call-site logic was dropped, reordered, or incompletely migrated +- whether downstream Qt6 targets depend strongly enough on generation to avoid race/order bugs + +### 3) Verify and fix generated-file CMake semantics +Inspect and correct where needed: + +- `add_custom_command(OUTPUT ...)` +- `BYPRODUCTS` +- `DEPENDS` +- `MAIN_DEPENDENCY` +- `WORKING_DIRECTORY` +- `COMMAND` +- `VERBATIM` +- `target_sources(...)` +- source properties such as `GENERATED` +- include directories for generated headers +- target-level dependencies via `add_dependencies(...)` +- attachment of generated sources to the correct consuming targets +- output paths using `${CMAKE_CURRENT_BINARY_DIR}` or other correct build-tree paths + +Prefer explicit and deterministic wiring over implicit behavior. + +### 4) Verify output placement +Confirm that generated files are emitted to the actual build-tree location expected by the Qt6 build. + +Check for: + +- stale Qt5-era output directories +- accidental source-tree output +- mismatch between parser CLI output arguments and CMake-declared outputs +- mismatch between generated paths and `target_sources(...)` +- missing directory creation for generated output folders + +### 5) Validate Docker-based Qt6 builds +Use the Docker environment defined by: + +- `./app/Dockerfile` + +Validate the Qt6 build end-to-end for both variants: + +- `BUILD_RTI=ON` +- `BUILD_RTI=OFF` + +For each variant, validate: + +- configure +- parser generation +- compilation +- generated-file discovery by consuming Qt6 targets + +If the Dockerfile or related build scripts need small changes to make this work reliably, implement the minimal necessary fixes. + +### 6) Validate external dependency and license mapping +Check and fix, if needed: + +- mapping of `./external` into the container/build environment +- availability of: + - `./external/rti_connext_dds-7.7.0` + - `./external/ArcGIS` + - `./external/GeographicLib` +- handling of `./rti_license.dat` +- any CMake or environment assumptions about external dependency paths +- whether `BUILD_RTI=ON` correctly finds RTI 7.7 from `./external/rti_connext_dds-7.7.0` +- whether `BUILD_RTI=ON` can access the RTI development license +- whether any RTI environment variables or license-path settings are required in the container +- whether `BUILD_RTI=OFF` avoids requiring RTI and its license at configure/build time + +### 7) Validate build correctness +Validate: + +- clean build behavior +- incremental build behavior +- regeneration when relevant RTI/codegen inputs change +- absence of missing dependency edges +- absence of ordering bugs hidden by pre-generated files +- no accidental dependence on undeclared timestamp side effects + +--- + +## Implementation requirements + +If issues are found, implement **minimal, reviewable fixes**. + +Allowed fix areas include: + +- incorrect invocation timing +- incomplete migration of macro/function call logic +- missing `DEPENDS`, `BYPRODUCTS`, `GENERATED`, or target dependencies +- incorrect output directories +- generated files not added to consuming targets +- generated headers not reachable through include paths +- parser invocation not happening before compilation +- incremental rebuilds not retriggering when inputs change +- incorrect `BUILD_RTI=ON` / `BUILD_RTI=OFF` behavior +- incorrect Docker/container mapping of external dependencies +- incorrect RTI license handling in containerized builds + +Do **not** re-port parser functionality unless a very small parser-side change is strictly required for build integration. + +Preserve existing Qt6 migration work and prefer the smallest correct changes. + +--- + +## Expected workflow + +1. Reconstruct the legacy Qt5 RTI codegen build flow. +2. Compare it with the Qt6 migrated flow. +3. Identify any missing or incorrect build-system migration details. +4. Implement minimal fixes. +5. Run Docker-based validation for: + - `BUILD_RTI=ON` + - `BUILD_RTI=OFF` +6. Verify clean and incremental rebuild behavior. +7. Provide a concise final report. + +--- + +## Final report requirements + +At the end, provide a concise summary covering: + +- original Qt5 invocation flow +- Qt6 invocation flow +- whether the Qt6 port matches the legacy build intent +- actual generated output locations +- which files/targets consume the generated outputs +- Docker validation results +- `BUILD_RTI=ON` result +- `BUILD_RTI=OFF` result +- external dependency mapping result +- RTI license handling result +- files changed +- issues found and fixes applied +- any remaining risks, assumptions, or unverifiable constraints + +--- + +## Acceptance criteria + +The task is complete only if all of the following are true: + +1. The original Qt5 RTI codegen invocation flow was reconstructed. +2. The Qt6 integration was compared against that flow. +3. The Qt6 parser/codegen is invoked automatically at the correct build stage. +4. Generated `.cpp` and headers are emitted to correct build-tree locations. +5. Consuming Qt6 targets reference the generated files from the real generated paths. +6. The Qt6 build was executed in the Docker environment from `./app/Dockerfile`. +7. Both variants were validated: + - `BUILD_RTI=ON` + - `BUILD_RTI=OFF` +8. External dependencies under `./external` were handled correctly. +9. RTI 7.7 and license handling were verified for `BUILD_RTI=ON`. +10. `BUILD_RTI=OFF` was verified to avoid RTI/license requirements. +11. Relevant CMake wiring is explicit and robust. +12. Clean and incremental builds were checked. +13. Any integration issues found were fixed with minimal changes. +14. A concise final report was provided with concrete results.