This commit is contained in:
7 files changed
+937
No files matched your search
@@ -0,0 +1,228 @@
|
||||
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.
|
||||
Reference in new issue
Block a user