qt6-migration-pipeline/prompts/grantlee-parser-toktexttemplate-integration-check.prompt.md

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.