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.