Files
qt6-migration-pipeline/.github/prompts/legacyrti_to_rti77_migration_prompt.md
T
torstenandCopilot d6500157f1 Fix RTI detection: only call FIND_PACKAGE if manual config failed
- Wrap FIND_PACKAGE(RTI) in IF(NOT TARGET RTI::nddsc) condition
- Prevents placeholder targets from overwriting manually configured RTI:: targets
- Manual configuration creates RTI:: targets when BUILD_RTI=ON and RTI found
- FIND_PACKAGE only called as fallback when manual config doesn't create targets

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Entire-Checkpoint: 01M1CT3XSQXCX9RQR6WM9DG3GH
2026-08-31 23:03:01 +02:00

198 lines
6.6 KiB
Markdown

You are working on a migration from RTI Connext 6 to RTI 7.7.
IMPORTANT:
Work in two strictly separated phases:
1. Analysis
2. Patching
Do not modify files before you have completed the analysis and written down a migration classification.
Your task is to compare:
- step-1 Copilot-created fallback/reconstructed RTI-related files created while `BUILD_RTI=OFF`
with
- real RTI 7.7 generated DDS/RTI artifacts created while `BUILD_RTI=ON`
Then update only the manually maintained / Copilot-created files so they correctly reflect the RTI 7.7 generated output.
## Main Goal
Make the codebase cleanly support the real RTI 7.7 generation in the `BUILD_RTI=ON` path, while preserving `BUILD_RTI=OFF` fallbacks only where truly necessary.
## Hard Rules
- Treat RTI 7.7 generated files as source of truth for `BUILD_RTI=ON`.
- Do not edit generated RTI files unless absolutely unavoidable and explicitly justified.
- Prefer adapting manual files, wrappers, compatibility headers, includes, and guards.
- Remove or isolate reconstructed definitions if they duplicate RTI 7.7 generated types.
- Keep fallback logic only for `BUILD_RTI=OFF`.
- Do not perform unrelated refactoring.
- Do not guess generated API shapes; inspect actual generated files.
## Required Workflow
# Phase 1 — Analysis only
## A. Identify migration-related files
Find:
- reconstructed RTI headers
- compiler guards added in step 1
- fallback DDS/RTI type definitions
- wrappers/adapters around DDS/RTI types
- include indirection layers
- files conditionally compiled for `BUILD_RTI`
Use repository inspection commands such as:
- `git status`
- `git diff --name-only`
- `git log --stat`
- `rg -n "BUILD_RTI|RTI|DDS|Connext|ifdef|ifndef|pragma once" .`
- `rg -n "#if.*BUILD_RTI|#ifdef.*BUILD_RTI|#ifndef.*BUILD_RTI" .`
- `find . -iname "*dds*" -o -iname "*rti*"`
If available, inspect step-1-related changes via:
- `git diff <baseline>...HEAD`
- `git log --grep="RTI\|DDS\|BUILD_RTI"`
- targeted diffs for migration commits
## B. Identify real RTI 7.7 generated artifacts
Locate the generated files produced with `BUILD_RTI=ON`.
Inspect:
- build directories
- generated include folders
- CMake-generated outputs
- RTI codegen output directories
- custom generation scripts
Use commands such as:
- `find build -type f | rg "dds|rti|idl|type|Support|Plugin"`
- `find . -type f | rg "Support\.h$|Plugin\.h$|Plugin\.cxx$|\.idl|\.xml"`
- `rg -n "rtiddsgen|connext|idl" CMakeLists.txt cmake/ .`
- `rg -n "GENERATED|AUTO_GENERATED|DO NOT EDIT" .`
## C. Compare reconstructed vs generated artifacts
For each reconstructed/manual RTI-related file, compare against the generated RTI 7.7 counterpart.
Check:
- file names
- include paths
- header guards / `#pragma once`
- macros
- namespaces
- class / struct / enum / typedef / alias definitions
- forward declarations
- helper APIs / traits / adapters
- symbol names
- expected include order
- conditional compilation behavior under `BUILD_RTI=ON` vs `BUILD_RTI=OFF`
Use comparison commands where helpful:
- `diff -u <manual-file> <generated-file>`
- `git diff --no-index <manual-file> <generated-file>`
- `rg -n "<TypeName>" .`
- `rg -n "#include <...>|#include \"...\"" <relevant paths>`
## D. Trace usage
Find all places that still reference the reconstructed step-1 artifacts.
Use:
- `rg -n "<header-name>|<type-name>|<guard-name>" .`
- `rg -n "#include .*<reconstructed-header>|#include .*\"<reconstructed-header>\"" .`
Determine:
- which files still depend on old reconstructed headers
- which guards still activate old fallback definitions
- which paths could conflict with generated RTI 7.7 types
## E. Build-path analysis
Inspect build logic and conditional compilation paths.
Check:
- `CMakeLists.txt`
- `*.cmake`
- generation scripts
- target include directories
- compile definitions
- `compile_commands.json` if present
Use:
- `rg -n "BUILD_RTI|target_include_directories|target_compile_definitions|add_definitions|include_directories" .`
- `find build -name compile_commands.json`
- inspect compile commands for affected targets
Goal:
Determine exactly how `BUILD_RTI=ON` and `BUILD_RTI=OFF` select different headers and definitions.
## F. Produce migration classification
Before patching, classify findings into:
- **REMOVE** = obsolete step-1 artifact replaced by RTI 7.7 generation
- **KEEP_OFF_ONLY** = still needed only when `BUILD_RTI=OFF`
- **PATCH** = manual file must be changed
- **VERIFY** = uncertain; validate before touching
Do not patch before this list is explicit.
# Phase 2 — Patching only after analysis
## Allowed patch types
- replace old includes with RTI 7.7 generated includes
- restrict fallback type definitions to `BUILD_RTI=OFF`
- tighten or invert guards so `BUILD_RTI=ON` always prefers generated output
- remove duplicate type declarations
- update wrappers/adapters to use actual RTI 7.7 generated types
- isolate obsolete reconstructed headers so they no longer affect `BUILD_RTI=ON`
- adjust build include paths only if necessary to stop wrong header selection
## Patch objectives
- `BUILD_RTI=ON` uses actual RTI 7.7 generated headers/types
- no old fallback header shadows generated output
- no duplicate definitions remain
- no stale RTI Connext 6 assumptions remain where RTI 7.7 differs
- `BUILD_RTI=OFF` stays supported only where explicitly needed
## Explicitly avoid
- editing generated files first
- broad renames
- non-migration-related cleanup
- speculative API rewrites
- silently dropping `BUILD_RTI=OFF` support
# Verification after patching
Run or propose the most relevant checks:
- `rg -n "<obsolete-header-or-type>" .`
- `rg -n "redefinition|redeclaration" <build logs if available>`
- project build with `BUILD_RTI=ON`
- if supported, project build with `BUILD_RTI=OFF`
- inspect compiler errors for include-order or duplicate-type issues
If build commands are available, use them. Typical examples:
- `cmake -S . -B build -DBUILD_RTI=ON`
- `cmake --build build -j`
- `cmake -S . -B build-off -DBUILD_RTI=OFF`
- `cmake --build build-off -j`
If tests exist and are relevant, run targeted tests only after the migration patches are in place.
## Output Format
First output:
1. **Analysis summary**
2. **Migration classification**
- REMOVE
- KEEP_OFF_ONLY
- PATCH
- VERIFY
Then patch files only after the analysis is complete.
For every changed file, report and write to ./RTI_MIGRATION_STATUS.md:
1. file path
2. category
3. problem found
4. exact change made
5. rationale
6. follow-up validation / residual risk
When uncertain, prefer minimal safe changes and document the uncertainty.
Start now with Phase 1 only.
Do not patch anything until the analysis and classification are complete.