qt6-migration-pipeline/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.