qt6-migration-pipeline/.github/prompts/legacyrti_to_rti77_migration_prompt.md

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.