lifemaps/qt6-migration-pipeline
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
ddca72a8565b20720d5ca73d00a35ca81ae71e30
qt6-migration-pipeline/prompts/migrate-module-TetraIF.prompt.md
T

17 KiB
Raw Blame History

Strict Qt6 Migration Prompt: CMake targets under folder ./TetraIF

This prompt is binding task context. Keep changes minimal, scoped, and reproducible.

Required base prompt

Before making changes, read and apply:

  • ./prompts/combined-migration-subfolder-rti-compact.prompt.md

If that prompt is stricter, follow it. This prompt overrides it only for build variants: use ON variants only. Do not pursue OFF variants.

Module in scope

Migrate only:

  • cmake targets under folder ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/TetraIF

From:

  • ./qt-migration-legatus/qt5-before/qt5-legatus-legacy/TetraIF

To:

  • ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/TetraIF

Do not migrate sibling services or unrelated modules.

Mandatory build variants

Only these variants are valid:

  • BUILD_RTI=ON
  • BUILD_GRANTLEE=ON
  • BUILD_ARCGIS=OFF

Forbidden:

  • BUILD_RTI=OFF
  • BUILD_GRANTLEE=OFF
  • BUILD_ARCGIS=ON

Rules:

  • Do not implement, fix, preserve, test, or validate OFF variants.
  • Do not add CMake logic, tests, stubs, or fallbacks for OFF variants.
  • Do not report OFF variants as supported or partially supported.
  • Validation must use BUILD_RTI=ON and BUILD_GRANTLEE=ON.

Branches and trees

Qt6 target branch:

  • feature/migrate-module-tetraif-only

Qt5 legacy branch, if comparison is needed:

  • story/qt6-migration

Legacy source tree:

  • ./qt-migration-legatus/qt5-before/qt5-legatus-legacy

Qt6 target tree:

  • ./qt-migration-legatus/qt6-after/qt6-migrated-legatus

Work in the Qt6 target tree only. Do not modify the Qt5 legacy tree.

Scope rules

Touch files outside the two target service directories only when directly required to configure, generate, build, link, test, or validate these services.

Allowed outside-scope changes:

  • parent CMakeLists.txt entries for these services
  • central CMake helper fixes required by these services
  • shared include path fixes required by these services
  • RTI, codegen, ndsgen, KTextTemplate, or Grantlee integration fixes required by these services
  • test infrastructure needed by tests for these services
  • new_docker_build.sh changes needed to run those tests
  • minimal Jenkins CI discovery or policy updates needed for those tests
  • relocation of required stubs or forward declarations to allowed directories

Not allowed:

  • restoring removed modules
  • reintroducing stale dependencies on removed modules
  • removing or disabling active modules to hide failures
  • disabling targets instead of fixing root causes
  • broad refactoring, cleanup, renaming, or modernization
  • warning suppression instead of fixing causes
  • committing generated files
  • consuming generated outputs from the source tree
  • fake success, dummy files, handwritten generated replacements, mocks, placeholders, or generated-output stubs

CMake targets under folder ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/TetraIF:

  • Discover real CMake targets defined under folder ./TetraIF when folder ./TetraIF exists.
  • Add every required CMake target under folder ./TetraIF to ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/new_docker_build.sh so the validation container builds or validates it.
  • Add every required CMake target under folder ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/TetraIF to ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/new_docker_build.sh so the validation container builds or validates it.
  • Add new --groupN (with number N) option for required CMake ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/TetraIF targets
  • Add required apt packages to new_docker_build.sh
  • Do not invent CMake targets under folder ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/TetraIF
  • Do not invent CMake targets under folder ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/TetraIF.
  • Do not add targets that do not exist.
  • If folder ./TetraIF does not exist, has no CMake targets, or a target is intentionally out of scope, report that fact and the reason.
  • Do not weaken validation to make CMake targets under folder ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/TetraIF pass.

Preservation rules

Preserve module removals from commit:

  • 92ad7d468, "remove all unneeded module listed from Niklas"

Do not restore removed modules, files, targets, directories, or dependencies.

Preserve LogViewer reinsert from commit:

  • 1fa789767, "Added LogViewer again"

Do not remove, disable, or break LogViewer integration.

Preserve prior IDL warning fixes from commit:

  • be912de9d, "Removes .IDL warnings: multiple enum definitons and builtin-type collisions"

Do not blindly replay that commit. Use it only as reference. Do not reintroduce removed modules.

IDL regressions to avoid:

  • multiple enum definitions
  • duplicate enumerators
  • builtin type or keyword collisions

Check first for duplicate inputs, stale paths, removed-module references, source-tree generated outputs, source/build-tree confusion, and repeated IDL definitions before treating an issue as semantic IDL conflict.

Stubs and forward declarations

Any required existing stub, compatibility declaration, or forward declaration must live only under:

  • ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/forward-declarations/
  • ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/.forward-declarations/include/

Rules:

  • Do not leave such files in source directories unless they are real source files.
  • Do not create or keep stubs for forbidden OFF variants.
  • Do not use stubs or forward declarations as replacements for real RTI, ndsgen, KTextTemplate, or Grantlee outputs in ON builds.
  • Report every moved, removed, or newly referenced stub/forward declaration.

Migration checks

For each cmake target, inspect and migrate only as needed:

  • source and header files
  • CMakeLists.txt and parent CMake registration
  • ui, qrc, resource, plugin, and service metadata
  • RTI IDL, ndsgen, KTextTemplate, and Grantlee inputs/templates
  • tests directly tied to these services

Fix only real Qt6/C++17 build issues, such as:

  • Qt module imports and target links
  • moc, uic, and rcc handling
  • QRegExp to QRegularExpression when required
  • QTextCodec replacement when required
  • QDesktopWidget or QApplication::desktop() replacement when required
  • QString, QVariant, QMetaType, QDateTime, QAction, QMenu, signal/slot, enum, plugin, or metadata compatibility issues when required

No opportunistic refactoring or style cleanup.

Qt link rules

No active target in the Qt6 tree may link Qt5 imported targets.

Search for and fix active uses of:

  • Qt5::
  • find_package(Qt5
  • QT5_
  • Qt5Core
  • Qt5Widgets
  • Qt5Network

Use Qt6 equivalents. Prefer central CMake helper fixes when the issue is central.

Code generation rules

If generated files are required:

  • reconstruct the real legacy generation flow
  • generate into the build tree
  • consume from the build tree
  • list complete OUTPUT and BYPRODUCTS
  • set correct DEPENDS and MAIN_DEPENDENCY where useful
  • use deterministic WORKING_DIRECTORY
  • use VERBATIM
  • wire generated sources with target_sources
  • wire generated include dirs with target_include_directories
  • ensure compilation depends on generation
  • ensure incremental rebuilds trigger on input/template changes

Never commit generated .idl, .h, .hpp, or .cpp outputs. Never consume generated outputs from the source tree. Never fabricate generated outputs.

Tests

For every C++ code change, add three meaningful CTest tests where feasible.

The tests must:

  • validate changed behavior, not only compilation

  • be registered with CTest

  • run with BUILD_RTI=ON and BUILD_GRANTLEE=ON

  • not add OFF-variant tests

  • be deterministic

  • avoid host-local paths

  • run reproducibly on Linux/Docker

  • use Qt6-compatible APIs

  • not introduce new Qt5-only APIs

  • preferably live under:

    ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/tests

If three meaningful tests are not possible, add the maximum meaningful set and briefly explain in the final result why three tests were not feasible.

Test types:

  1. Unit Tests

    Add targeted unit tests for isolated changed C++/Qt components.

    Examples:

    • changed QString/QByteArray/QVariant conversions
    • signal/slot behavior after Qt6 adjustments
    • model/delegate/proxy-model logic
    • parsing, mapping, or validation logic
    • Qt6 API migration behavior, such as enum class changes, QStringView, QRegularExpression, QDateTime, or QTextCodec replacements

  2. Functional Tests

    Add functional tests that validate visible or user-relevant behavior.

    Functional tests should verify that a TetraIF feature works correctly from the user’s perspective, for example:

    • loading or initializing a TetraIF module
    • correctly creating, updating, or filtering data handled by TetraIF
    • expected signal emission after user-like or API-triggered actions
    • correct behavior of commands, actions, interfaces, adapters, or service-facing components
    • correct rendering or preparation of Grantlee-based templates, where relevant
    • expected handling of valid and invalid input

    Functional tests may use Qt test frameworks such as QTest, but they must not require real host-system user interaction, non-deterministic timing, or external resources.

  3. Integration Tests

    Add integration tests that validate interaction between multiple migrated components.

    Integration tests should specifically check:

    • interaction between TetraIF components and shared project components
    • CMake target linkage with BUILD_RTI=ON and BUILD_GRANTLEE=ON
    • integration of Grantlee-dependent components
    • integration of RTI-dependent components, where meaningful without external infrastructure
    • initialization paths that may behave differently under Qt6
    • signal/slot communication across multiple objects
    • object lifetime, parent/child relationships, and QObject ownership after the Qt6 migration

    Integration tests must be reproducible in the Docker build and must not require external services, host-local files, or manual setup.

CTest/CMake requirements:

  • All new tests must be registered with CTest.

  • Add or update the necessary CMakeLists.txt files.

  • Ensure test targets are built when BUILD_RTI=ON and BUILD_GRANTLEE=ON are enabled.

  • Use policy-compatible test file names, for example:

    test_.cpp _test.cpp test.cpp _gtest.cpp

  • Do not use file names that violate existing project or CMake policies.

  • Do not add tests that only verify a target compiles.

  • Every test must contain concrete assertions about behavior.

  • Use stable, descriptive test names, for example:

    TetraIFModelMigratesQt6Behavior TetraIFTemplateRenderingUsesGrantlee TetraIFSignalsRemainCompatibleWithQt6

Docker build requirements:

Update the following script if needed:

./qt-migration-legatus/qt6-after/qt6-migrated-legatus/new_docker_build.sh

The script must be able to build and run the new or modified tests.

Required:

  • BUILD_RTI=ON

  • BUILD_GRANTLEE=ON

  • CMake configuration for the relevant targets under:

    ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/TetraIF

  • execution of the relevant CTest tests

  • output clearly showing which tests were built and executed

  • no OFF variants

  • no host-local absolute paths

  • no assumptions about local developer environments

If the script already has a suitable build/CTest path, extend it minimally. If the script does not run tests yet, add robust CTest execution for the newly relevant targets.

Preferred workflow:

  1. Analyze the existing CMake structure under TetraIF and tests.
  2. Identify the changed or still-to-be-migrated Qt5 components.
  3. Add Qt6-compatible unit, functional, and integration tests.
  4. Register all tests with CTest.
  5. Ensure the tests build with BUILD_RTI=ON and BUILD_GRANTLEE=ON.
  6. Update new_docker_build.sh so it builds or validates the relevant TetraIF CMake targets and runs the tests.
  7. Run the build and tests where possible.
  8. Document in the final result:
    • which tests were added
    • which behavior they validate
    • which CMake files were changed
    • what changed in new_docker_build.sh
    • whether three tests per C++ change were feasible
    • if not, why fewer tests were meaningful

Acceptance criteria:

  • New or changed C++ logic is covered by meaningful tests.
  • Functional tests validate actual TetraIF behavior.
  • Integration tests validate interaction between multiple components.
  • Tests are registered with CTest.
  • Tests run with BUILD_RTI=ON and BUILD_GRANTLEE=ON.
  • No OFF-variant tests are added.
  • Tests are deterministic and independent of host-local paths.
  • new_docker_build.sh builds or validates the required CMake targets under TetraIF.
  • new_docker_build.sh runs the relevant CTest tests.
  • The solution remains minimally invasive and compatible with the ongoing Qt5-to-Qt6 migration.

Docker and CI

Authoritative migration Dockerfile:

  • ./app/Dockerfile

Authoritative validation script:

  • ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/new_docker_build.sh

Do not use other Dockerfiles as task authority.

Validation container expectations:

  • repository root at /repo, or the script's documented mount path
  • external dependencies under /repo/external, or the script's documented equivalent
  • RTI 7.7 at /repo/external/rti_connext_dds-7.7.0, or documented equivalent
  • ./rti_license.dat mounted read-only if RTI requires it
  • no developer-local paths

Jenkins CI must be able to discover and run the new tests, or verify that new_docker_build.sh runs them. Inspect and minimally update only if needed:

  • ./qt-migration-legatus/ci/Dockerfile.*
  • ./qt-migration-legatus/ci/check_pr_policies.py

Required procedure

  1. Inspect repository state, branch, working tree, submodules, required prompts, service paths, and forward-declaration directories.
  2. Compare Qt5 source services with Qt6 targets. Classify files as already migrated, missing, stale, generated, intentionally removed, build-only, or needing Qt6 adaptation.
  3. Identify dependencies, generated inputs, Qt modules, parent CMake entries, removed-module references, LogViewer interactions, and required stub/forward-declaration relocations.
  4. Apply the smallest valid migration changes.
  5. Add required CTest tests for C++ changes.
  6. Review RTI, ndsgen, KTextTemplate, and Grantlee generation paths.
  7. Check regressions: Qt5 links, removed modules, LogViewer, IDL warnings, source-tree generated consumption, stale artifacts, and misplaced stubs.
  8. Validate in Docker with BUILD_RTI=ON and BUILD_GRANTLEE=ON.
  9. Run CTest in the validated build directory.
  10. Check Jenkins/policy compatibility.
  11. Report factual status.

Do not overwrite uncommitted user changes. If they block safe work, report the blocker.

Required validation

From:

  • ./qt-migration-legatus/qt6-after/qt6-migrated-legatus

Run:

BUILD_RTI=ON BUILD_GRANTLEE=ON ./new_docker_build.sh

CTest must run as part of validation. If a direct clean build is useful, use:

cmake -S /repo/qt-migration-legatus/qt6-after/qt6-migrated-legatus -B /repo/build-rti-on-grantlee-on -G Ninja -DCMAKE_BUILD_TYPE=Debug -DBUILD_RTI=ON -DBUILD_GRANTLEE=ON
cmake --build /repo/build-rti-on-grantlee-on --parallel
ctest --test-dir /repo/build-rti-on-grantlee-on --output-on-failure

Also check whether this file exists and run it only if present:

./new_docker-build.h

If it is absent or a typo, report that. Do not invent a replacement.

Do not run or validate OFF variants.

Success criteria

Success requires:

  • cmake targets migrated or confirmed already correct
  • cmake targets included in the Qt6 build
  • configure, build, and CTest pass with BUILD_RTI=ON and BUILD_GRANTLEE=ON
  • new_docker_build.sh runs the relevant tests and fails on test failure
  • Jenkins/policy discovery accepts the new tests and validation changes
  • no active Qt5 imported target links remain for these services
  • generated outputs are build-tree only and freshly produced when required
  • no generated outputs are committed or consumed from the source tree
  • no fake generated files, dummy files, mocks, placeholders, or stubbed generated outputs exist
  • required stubs/forward declarations are only in allowed directories
  • removed modules remain removed
  • LogViewer remains preserved
  • RoutingServiceNG prompt rules are followed
  • RTI/codegen and Grantlee/KTextTemplate success is real, not stale or faked

If blocked

Do not fake success. Report:

  • failing command
  • key error output
  • affected service
  • category: project, path, merge, CMake, Qt API, codegen, Docker, RTI/license, Grantlee/KTextTemplate, test, CTest, Jenkins CI, stub relocation, or environment
  • what was fixed safely
  • what remains blocked
  • whether stale artifacts were ruled out
  • whether generated files were involved
  • exact missing files, targets, or generator step
  • whether tests and CTest integration succeeded
  • whether Docker validation and Jenkins discovery succeeded

Final report

Keep it short. Include:

  • status: validated, partially validated, or blocked
  • cmake targets under folder ./TetraIF migrated or already correct
  • files changed
  • C++ files changed
  • tests added per C++ change
  • CTest registration changes
  • CMake and generator changes
  • stub/forward-declaration moves or removals
  • Docker and Jenkins CI changes
  • Qt5 references removed or remaining
  • confirmation that removed modules were not restored
  • confirmation that LogViewer was preserved
  • exact validation commands and results
  • result of new_docker-build.h if present
  • remaining blockers or risks
Reference in new issue View Git Blame Copy Permalink