qt6-migration-pipeline/prompts/legacyrti_to_rti77_migration_prompt.md

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.