229 lines
7.9 KiB
Markdown
229 lines
7.9 KiB
Markdown
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.
|