lifemaps/qt6-migration-pipeline
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
qt6-migration-pipeline/prompts/strict-lts-services-s-migration.prompt.md
T
torsten 0b89aa43fb
Qt6 Migration CI / migrate (push) Waiting to run
Details
Inserts forward decl into prompt
2026-09-16 10:04:17 +00:00

31 KiB
Raw Permalink Blame History

Use all rules, hard requirements, and diagnostic guidance from this chat as binding task context.

Also use and preserve the rules from the prompt named:

  • GitHub Copilot Instructions: RoutingServiceNG Qt5 -> Qt6 Migration

The prompt named:

  • GitHub Copilot Instructions: RoutingServiceNG Qt5 -> Qt6 Migration

is available in the repository at:

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

Read this file before making changes.

Treat its rules as binding context for this migration. If any rule from that prompt is stricter than this prompt, follow the stricter rule. Do not ignore its Docker, RTI, codegen, validation, no-stub, no-fake-success, and scope-control requirements.

Work autonomously, minimally, and reproducibly. Do not stop after editing. Continue through analysis, implementation, Docker validation, unit-test validation, Jenkins CI compatibility checks, and final reporting. Ask for confirmation only if the task is impossible, destructive, or source material is missing.

Task

Migrate the following Qt5 services to Qt6:

  • Lts/ScreenRecording/
  • Lts/ServiceManagement/
  • Lts/ServiceMonitor/
  • Lts/SituationMap/
  • Lts/SituationReplay/
  • Lts/SituationReplayManagement/
  • Lts/SoundManagement/

Source tree:

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

Target tree:

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

Qt6 target branch:

  • feature/qt6-migration-basis-modules

Qt5 legacy branch, if source inspection or comparison is needed:

  • story/qt6-migration

Main Objective

Migrate only the listed services from the Qt5 legacy tree into the Qt6 migrated tree.

Make the listed services correctly configured, generated, compiled, linked, tested, and validated in the Qt6 build while preserving all existing Qt6 migration fixes.

Do not migrate unrelated modules.

Do not perform opportunistic cleanup, broad refactoring, or unrelated modernization.

Strict Scope

Only these service directories are in scope:

  • ./qt-migration-legatus/qt5-before/qt5-legatus-legacy/Lts/ScreenRecording/
  • ./qt-migration-legatus/qt5-before/qt5-legatus-legacy/Lts/ServiceManagement/
  • ./qt-migration-legatus/qt5-before/qt5-legatus-legacy/Lts/ServiceMonitor/
  • ./qt-migration-legatus/qt5-before/qt5-legatus-legacy/Lts/SituationMap/
  • ./qt-migration-legatus/qt5-before/qt5-legatus-legacy/Lts/SituationReplay/
  • ./qt-migration-legatus/qt5-before/qt5-legatus-legacy/Lts/SituationReplayManagement/
  • ./qt-migration-legatus/qt5-before/qt5-legatus-legacy/Lts/SoundManagement/

to:

  • ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/Lts/ScreenRecording/
  • ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/Lts/ServiceManagement/
  • ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/Lts/ServiceMonitor/
  • ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/Lts/SituationMap/
  • ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/Lts/SituationReplay/
  • ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/Lts/SituationReplayManagement/
  • ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/Lts/SoundManagement/

Touch files outside these directories only if one of the listed services cannot be configured, generated, compiled, linked, tested, or validated without a minimal directly related fix.

Allowed minimal outside-scope changes include only:

  • parent CMakeLists.txt entries needed to include the listed services
  • central CMake helper fixes required by these services
  • shared interface/header include path fixes required by these services
  • RTI/codegen/KTextTemplate integration fixes required by these services
  • forward declaration files under ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/forward-declarations when required for optional builds such as BUILD_RTI=OFF
  • test infrastructure changes required by the new tests for these services
  • validation container changes required to run the new tests
  • Jenkins CI changes required to discover and run the new tests
  • Docker or validation script fixes only if directly required for these services

Not allowed:

  • migrating sibling services
  • migrating unrelated Lts modules
  • restoring removed modules
  • removing active modules to make the build pass
  • disabling targets instead of fixing root causes
  • warning suppression as a substitute for fixing the actual cause
  • generated files committed to the repository
  • source-tree consumption of generated RTI/KTextTemplate outputs
  • stubs, dummy files, placeholders, mocks, or handwritten replacements for generated outputs

Hard Preservation Boundary for Removed Modules

Respect the previous module removal:

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

These module removals must remain fully preserved.

Do not:

  • restore removed modules
  • restore removed files, targets, or directories
  • add dependencies on removed modules
  • reintroduce stale references to removed modules
  • blindly replay old fixes if they affect removed modules

If one of the listed services appears to depend on a removed module:

  • first verify whether the dependency is stale or accidental
  • do not restore the removed module
  • remove or adapt only the stale reference if that is the correct minimal fix
  • report the dependency and decision clearly

Hard Preservation Boundary for Reinserted LogViewer Module

Observe the module reinsert in submodule:

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

Relevant commit:

  • 1fa789767
    • Merge pull request 'Added LogViewer again' (#2) from feature/qt6-migration-added-logview into feature/qt6-migration-basis-modules

This module must remain fully preserved.

Do not remove, disable, or break LogViewer integration while migrating the listed services.

If a central CMake, shared interface, test infrastructure, validation container, or Jenkins CI change affects LogViewer, verify that LogViewer remains included and buildable.

Previous .IDL Warning Fixes Must Not Regress

Relevant commits:

  • 44fdf2ac9

    • current HEAD / merge baseline
    • contains module removals from the merge context

  • 92ad7d468

    • remove all unneeded module listed from Niklas

  • be912de9d

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

Treat .IDL warnings as a regression-sensitive area.

Do not blindly cherry-pick or replay be912de9d.

Use be912de9d only as a reference for the intended fix.

If warnings reappear, investigate whether be912de9d was effectively undone, bypassed, or made irrelevant by later tree changes.

Adopt only still-relevant parts of the old fix, adapted minimally to the current Qt6 tree and current module set.

Do not bring back modules removed by 92ad7d468.

Warning classes that must not regress include:

  • multiple enum definitions
  • duplicate enumerators
  • builtin-type / keyword collisions

Example problematic symbols include:

  • On
  • Off
  • Normal
  • Undefined
  • bitMask
  • typeId
  • eventType

First check whether warnings are caused by:

  • duplicate IDL inputs
  • old paths
  • duplicate code generation sources
  • wrong include/import order
  • stale artifacts
  • removed but still referenced modules
  • source-tree generated artifacts being consumed
  • build-tree/source-tree output confusion
  • the same .idl definitions being passed more than once

Only after excluding those causes, treat the problem as a real semantic IDL/XTypes conflict.

Qt5 to Qt6 Migration Requirements

For each listed service, inspect and migrate:

  • source files
  • headers
  • CMakeLists.txt
  • parent CMakeLists.txt registration
  • resource files
  • ui files
  • qrc files
  • plugin metadata
  • service registration metadata
  • generator inputs
  • KTextTemplate templates
  • RTI/IDL files
  • ndsgen inputs
  • test targets, if directly tied to the listed services

Check and fix as needed:

  • Qt5 to Qt6 API compatibility
  • C++17 compatibility
  • Qt module imports
  • Qt target links
  • moc/uic/rcc handling
  • QRegExp to QRegularExpression where required
  • QString API changes where required
  • QVariant/QMetaType changes where required
  • QDateTime/time API changes where required
  • QTextCodec replacements if required
  • QAction/QMenu API differences if required
  • signal/slot syntax issues
  • enum scoping issues
  • plugin macro and metadata compatibility
  • CMake target inclusion
  • include directories
  • generated source/header registration
  • generation-to-compilation dependency order
  • build-tree output placement
  • incremental rebuild triggers

Do not perform unrelated API modernization.

Unit Test Requirements

For every C++ code change made during this migration, create three unit tests.

Rules:

  • add exactly three meaningful unit tests per C++ code change where feasible
  • tests must validate the changed behavior, not only compile presence
  • tests must be runnable through CTest
  • tests must be integrated into the Qt6 CMake build
  • tests must not require RTI or an RTI license when BUILD_RTI=OFF
  • if a changed C++ component depends on RTI/codegen, provide tests that are valid for the supported build variant and clearly report any RTI-only test limitation
  • do not add superficial tests just to satisfy the count
  • if three meaningful tests are impossible for a specific change, explain why in the final report and add the maximum meaningful set

CTest integration requirements:

  • register each test with add_test or the project's existing CTest helper
  • ensure tests are built as part of the normal validation target or test target
  • ensure ctest --test-dir --output-on-failure runs the new tests
  • ensure test names clearly identify the migrated service and behavior
  • ensure tests are deterministic and do not depend on host-local paths
  • ensure tests do not consume stale generated artifacts
  • ensure tests use build-tree generated files when generated files are required

Validation Container Test Integration

The new unit tests must be integrated into the validation container flow.

The validation script:

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

must build and run the new CTest tests as an explicit validation step, unless it already does so.

If docker_build.sh already runs CTest:

  • verify that the new tests are included in that CTest run
  • verify that failing tests fail the container validation
  • do not duplicate test execution unnecessarily

If docker_build.sh does not run CTest:

  • add the minimal required CTest execution step
  • use the existing build directory used by the script
  • run CTest with output-on-failure
  • make test failure propagate as a non-zero exit code

Required validation behavior:

  • BUILD_RTI=OFF ./docker_build.sh must run the new tests when BUILD_RTI=OFF supports the migrated code
  • BUILD_RTI=ON ./docker_build.sh must run the new tests when BUILD_RTI=ON is supported and relevant
  • test execution must not rely on stale build directories
  • test execution must not rely on developer-local artifacts

Jenkins CI Test Discovery and Execution

The new unit tests and their execution must also be discoverable and usable by the Jenkins CI environment.

Inspect and minimally update, if needed:

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

Requirements:

  • Jenkins CI must be able to discover the new CTest tests
  • Jenkins CI must be able to build the test targets
  • Jenkins CI must be able to execute the tests or verify that the validation container executes them
  • check_pr_policies.py must not reject the new test files, test CMake integration, or required validation-script changes
  • CI Dockerfiles must contain only minimal directly required dependency changes
  • do not add unrelated CI tooling
  • do not introduce host-specific assumptions
  • do not make Jenkins depend on RTI or an RTI license for BUILD_RTI=OFF validation
  • if RTI-specific tests exist, gate them correctly behind BUILD_RTI=ON or the project's existing RTI test mechanism

If Jenkins already discovers and runs CTest automatically:

  • verify and report that no CI changes were needed

If Jenkins does not discover the new tests:

  • apply the smallest project-consistent fix so the tests are found and executed

Qt5:: to Qt6:: Link Rules

In the Qt6 migrated tree, no active target may link against Qt5 imported targets.

Search the Qt6 tree for:

  • Qt5::
  • Qt5::Core
  • Qt5::Gui
  • Qt5::Widgets
  • Qt5::Network
  • Qt5::Sql
  • Qt5::Xml
  • Qt5::Test
  • Qt5::Concurrent
  • Qt5::PrintSupport
  • Qt5::OpenGL
  • find_package(Qt5
  • QT5_
  • Qt5Core
  • Qt5Widgets
  • Qt5Network

Replace or centralize to Qt6 equivalents as appropriate:

  • Qt5::Core -> Qt6::Core
  • Qt5::Gui -> Qt6::Gui
  • Qt5::Widgets -> Qt6::Widgets
  • Qt5::Network -> Qt6::Network
  • Qt5::Sql -> Qt6::Sql
  • Qt5::Xml -> Qt6::Xml
  • Qt5::Test -> Qt6::Test
  • Qt5::Concurrent -> Qt6::Concurrent
  • Qt5::PrintSupport -> Qt6::PrintSupport
  • Qt5::OpenGL -> Qt6::OpenGL or Qt6::OpenGLWidgets depending on actual API usage

Prefer fixing a central CMake helper or macro if the Qt5 references originate there.

Only edit individual CMakeLists.txt files if the references are local.

Ensure the required Qt6 components are included in find_package(Qt6 COMPONENTS ... REQUIRED) or the project's equivalent Qt discovery mechanism.

Avoid adding unnecessary Qt components.

CMake Integration Requirements

For each listed service, verify:

  • service directory is included by the correct parent CMakeLists.txt
  • target name is correct and does not collide
  • target type is correct: library, plugin, executable, test, or service
  • all real source files are registered
  • all required headers are reachable
  • all generated sources are registered
  • all generated headers are reachable
  • all dependencies are valid and still exist
  • no removed module is referenced
  • no Qt5 imported target is linked
  • install rules, if present, are still valid
  • plugin/service registration remains correct

Inspect central helper files if involved, for example:

  • ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/cmake/NGLMacros.cmake
  • other cmake/*.cmake files used by the listed services

If central macros still encode Qt5 behavior, fix the smallest central abstraction rather than patching many targets individually.

RTI / Codegen / KTextTemplate Rules

If any listed service depends on generated files, reconstruct the real legacy generation flow and port it correctly.

Generated files may include:

  • .idl
  • .h
  • .hpp
  • .cpp
  • RTI generated files
  • ndsgen generated files
  • KTextTemplate generated files

Rules:

  • generated outputs must be created in the build tree
  • generated outputs must be consumed from the build tree
  • generated outputs must not be committed to the source repository
  • generated outputs must not be consumed from the source tree
  • no stale generated source-tree artifacts may be required
  • no developer-local generated artifacts may be required
  • no stubs, dummies, placeholders, mocks, or handwritten substitutes are allowed

Inspect and fix if needed:

  • add_custom_command(OUTPUT ...)
  • BYPRODUCTS
  • DEPENDS
  • MAIN_DEPENDENCY
  • WORKING_DIRECTORY
  • COMMAND
  • VERBATIM
  • target_sources(...)
  • target_include_directories(...)
  • add_dependencies(...)
  • GENERATED
  • build-tree include directories
  • generator input lists
  • duplicate generator inputs
  • removed module references
  • stale generated outputs

Prefer output paths under:

  • ${CMAKE_CURRENT_BINARY_DIR}

unless the repository clearly requires another build-tree path.

Forward Declaration Rules for Optional Builds

If forward declarations are required for optional builds, for example BUILD_RTI=OFF, they must be placed under:

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

Rules:

  • do not place forward declaration headers ad hoc in service source directories unless the repository already has a stricter established pattern for that exact service
  • do not create forward declarations as substitutes for real generated outputs in BUILD_RTI=ON
  • do not use forward declarations to fake successful RTI/codegen validation
  • forward declarations may only model the minimal type declarations needed for non-RTI or optional-codegen compilation
  • forward declaration files must be clearly wired through CMake include paths for the affected BUILD_RTI=OFF targets
  • BUILD_RTI=ON must still use real generated outputs from the build tree when those outputs are required
  • report every added or changed forward declaration file in the final report

If required generated files cannot be produced by the real generator flow:

  • do not fabricate them
  • do not weaken dependencies just to continue
  • do not claim success
  • report the missing generated files and blocked generator step exactly

RoutingServiceNG Prompt Compatibility

Apply the migration style and constraints from:

  • GitHub Copilot Instructions: RoutingServiceNG Qt5 -> Qt6 Migration

In particular:

  • read ./prompts/combined-migration-subfolder-rti-compact.prompt.md before changes
  • follow the same minimal-migration discipline
  • preserve branch and Docker rules
  • preserve Qt6 build integration patterns
  • preserve service/module registration patterns
  • preserve generated-output build-tree rules
  • preserve validation expectations
  • preserve no-stub and no-fake-success behavior
  • if RoutingServiceNG established project-specific CMake helper patterns, reuse those patterns for the listed services instead of inventing a parallel approach
  • if RoutingServiceNG established Qt6 replacements for project-specific Qt5 APIs, apply the same style where directly applicable

Do not migrate RoutingServiceNG again unless a central fix is required and directly affects the listed services.

Docker Authority

There are many Dockerfiles in the repository.

For the migration environment, only this Dockerfile is authoritative:

  • ./app/Dockerfile

For validation, use:

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

Do not use other Dockerfiles as authority for this task.

The migration must remain possible with:

  • ./app/Dockerfile

Validation must be performed with:

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

Container and Mount Rules

General required container layout:

  • repository root at /repo
  • external dependencies at /repo/external
  • RTI 7.7 at /repo/external/rti_connext_dds-7.7.0
  • license file from ./rti_license.dat mounted read-only if RTI requires it

The existing validation container may use:

  • /workspace

Respect the project script's mount convention.

Do not introduce host-specific assumptions.

If RTI requires environment variables or explicit license path configuration:

  • set them minimally and explicitly
  • do not hardcode developer-local paths

BUILD_RTI Rules

If BUILD_RTI is supported, validate both variants where possible:

  • BUILD_RTI=ON
  • BUILD_RTI=OFF

For BUILD_RTI=ON, success may only be reported if all of the following are proven:

  • build ran inside Docker
  • old generated artifacts relevant to the listed services were removed, invalidated, or proven irrelevant
  • the required generator actually ran during the Docker build
  • new generated files were created in the current build
  • consuming targets compiled against those newly generated files
  • success did not depend on stale source-tree artifacts
  • success did not depend on stale build-tree artifacts
  • success did not depend on developer-local artifacts
  • /repo/external/rti_connext_dds-7.7.0, or the corresponding container path, worked
  • ./rti_license.dat was correctly mounted if required
  • new RTI-dependent tests were executed if applicable and supported

If not all of this is proven, report:

  • BUILD_RTI=ON not fully validated

For BUILD_RTI=OFF, verify:

  • build does not require RTI
  • build does not require an RTI license
  • optional RTI codegen parts are cleanly disabled or not consumed
  • no stale generated RTI artifacts are required
  • new non-RTI tests run successfully through CTest
  • forward declarations required for BUILD_RTI=OFF are provided only through ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/forward-declarations

Procedure

Phase 1: Repository and Branch State

Start from repository root.

Check:

  • current branch
  • current working tree
  • submodule status, if applicable
  • existence of target branch feature/qt6-migration-basis-modules
  • existence of source branch story/qt6-migration if needed
  • presence of ./prompts/combined-migration-subfolder-rti-compact.prompt.md
  • presence of the listed source service directories
  • presence or absence of corresponding Qt6 target service directories
  • presence of ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/forward-declarations

Do not overwrite local changes.

If uncommitted local changes exist:

  • inspect them
  • preserve them
  • avoid overwriting them
  • report if they block safe work

Phase 2: Source-to-Target Comparison

For each listed service, compare the Qt5 legacy source with the current Qt6 target.

Classify files as:

  • already migrated
  • missing in Qt6
  • present but stale
  • present but still Qt5-specific
  • generated and should not be copied
  • removed intentionally
  • CMake/build integration only
  • needs manual Qt6 adaptation

Do not copy generated artifacts from Qt5 source into Qt6 source.

Do not copy stale source-tree generated files.

Phase 3: Dependency and Scope Check

For each listed service, identify:

  • local dependencies
  • shared libraries
  • plugin interfaces
  • service interfaces
  • generated code dependencies
  • RTI/IDL dependencies
  • KTextTemplate dependencies
  • Qt modules
  • parent CMake dependencies
  • removed-module references
  • LogViewer interactions
  • RoutingServiceNG pattern dependencies
  • required forward declarations for optional builds such as BUILD_RTI=OFF

Decide whether each dependency:

  • exists and is valid
  • needs Qt6 migration
  • is already migrated
  • is outside scope but required
  • is stale and should be removed
  • belongs to a removed module and must not be restored
  • must be represented by a minimal forward declaration for BUILD_RTI=OFF under ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/forward-declarations

If a dependency is outside scope but required to build, test, or validate a listed service, apply the smallest directly related fix only.

Phase 4: Implement Minimal Qt6 Migration

For each listed service:

  • add or update only required real source files
  • adapt Qt APIs minimally
  • update includes minimally
  • update local CMakeLists.txt
  • update parent CMakeLists.txt only as needed
  • update target_sources only with real source files or real generated build-tree outputs
  • update target_link_libraries to Qt6 targets and valid project targets
  • update target_include_directories to include build-tree generated output dirs where required
  • add or update BUILD_RTI=OFF forward declarations only under ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/forward-declarations when required
  • preserve service/plugin metadata
  • preserve install rules if valid
  • remove stale references to missing or removed files only if they are truly stale

Do not remove a target merely because it fails unless the target belongs to a removed module or is proven out of scope and accidentally referenced.

Phase 4b: Add Unit Tests for C++ Changes

For every C++ code change made in the listed services or directly related shared code:

  • identify the behavior changed
  • add three meaningful unit tests for that behavior where feasible
  • integrate the tests into the local CMake/CTest setup
  • ensure the tests build in the Qt6 tree
  • ensure the tests run through ctest
  • ensure the tests are included in Docker validation
  • ensure Jenkins CI can discover and use the tests

Do not add tests for unrelated modules. Do not modify unrelated test infrastructure.

Phase 5: Codegen Review

For every generated dependency involved in the listed services:

  • verify generator input files exist
  • verify templates exist
  • verify command line uses correct source and build paths
  • verify outputs are in the build tree
  • verify BYPRODUCTS are complete
  • verify DEPENDS include all inputs/templates/scripts
  • verify MAIN_DEPENDENCY is set where useful
  • verify WORKING_DIRECTORY is deterministic
  • verify VERBATIM is used
  • verify generated .cpp files are registered in target_sources
  • verify generated headers are included through build-tree include directories
  • verify compilation depends on generation
  • verify incremental rebuild triggers when input/template changes
  • verify BUILD_RTI=OFF forward declarations, if needed, are located under ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/forward-declarations and do not replace real BUILD_RTI=ON generated outputs

If generation cannot run:

  • do not create fake outputs
  • report exact blocked generator step and root cause

Phase 6: Regression Check

Check that the migration did not regress:

  • previous .IDL warning fixes from be912de9d
  • module removals from 92ad7d468
  • LogViewer reinsert from 1fa789767
  • RoutingServiceNG migration behavior
  • Qt6-only target links
  • build-tree-only generated outputs
  • Docker validation flow
  • BUILD_RTI=OFF behavior
  • CTest integration
  • Jenkins CI test discovery

Search the Qt6 tree after changes for:

  • Qt5::
  • find_package(Qt5
  • source-tree generated .idl/.h/.cpp consumption
  • references to removed modules
  • duplicate IDL input lists
  • stale generated output directories
  • misplaced forward declarations outside ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/forward-declarations

Validation Requirements

Before final validation:

  • use clean or empty build directories
  • remove or invalidate stale generated artifacts relevant to the listed services, or prove they are irrelevant
  • ensure no generated files are consumed from source tree
  • ensure required generators run during the build if needed
  • validate inside Docker
  • run CTest as part of validation
  • verify optional-build forward declarations are loaded from ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/forward-declarations when required

At minimum, run from:

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

the validation command:

  • BUILD_RTI=OFF ./docker_build.sh

If BUILD_RTI=ON is supported and relevant, run:

  • BUILD_RTI=ON ./docker_build.sh

CTest must be run as part of validation.

At minimum, after a successful configure/build, run:

  • ctest --test-dir --output-on-failure

The validation container must also run the same relevant CTest set.

For BUILD_RTI=OFF:

  • run all tests valid without RTI
  • prove the new tests do not require RTI/license unless explicitly gated off

For BUILD_RTI=ON:

  • run RTI-dependent tests only if BUILD_RTI=ON is supported and the RTI/license setup is available
  • report BUILD_RTI=ON as not fully validated unless the tests and generation requirements are actually proven

If direct CMake validation inside the container is useful, use clean build directories:

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

If BUILD_RTI=ON is supported:

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

Also check whether this command exists and run it if present:

  • ./docker-build.h

If the command name is a typo or does not exist, report that explicitly and do not invent an equivalent unless the repository clearly documents one.

Success Criteria

The task is successful only if:

  • all listed services are migrated or confirmed already correctly migrated
  • each listed service is correctly included in the Qt6 build if it is an active service
  • Qt6 configure succeeds
  • Qt6 build succeeds for the validated variant
  • CTest runs successfully for the validated variant
  • three meaningful CTest unit tests were added for every C++ code change, or any justified exception is reported
  • new tests are registered with CTest
  • new tests run inside the validation container
  • Jenkins CI can discover and use the new tests through ./qt-migration-legatus/ci/Dockerfile.* and ./qt-migration-legatus/ci/check_pr_policies.py
  • no listed service links against Qt5 imported targets
  • required Qt6 components are found and linked
  • generated outputs, if involved, are produced in the build tree
  • generated outputs, if involved, are consumed from the build tree
  • no generated .idl, .h, or .cpp files are committed to source
  • no stub/dummy/mock/placeholder generated files are created
  • optional-build forwarddeclarations, if needed, are placed under ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/forward-declarations
  • forward declarations are not used as fake replacements for real BUILD_RTI=ON generated outputs
  • previous .IDL warning fixes do not regress
  • modules removed by 92ad7d468 remain removed
  • LogViewer reinsert from 1fa789767 remains preserved
  • RoutingServiceNG migration rules and patterns are not violated
  • BUILD_RTI=OFF does not require RTI or an RTI license
  • BUILD_RTI=ON is reported successful only if real RTI/codegen execution, fresh generated outputs, and relevant tests are proven

If Blocked

Do not fake success.

Report exactly:

  • failing command
  • key error output
  • affected service
  • whether the issue is project, path, merge, CMake, Qt API, codegen, Docker, RTI/license, test, CTest, Jenkins CI, forward declaration, or environment related
  • what was fixed safely
  • what remains blocked
  • whether BUILD_RTI=OFF was validated
  • whether BUILD_RTI=ON was validated or not fully validated
  • whether stale artifacts were ruled out
  • whether generated files were involved
  • exact missing files or targets
  • exact blocked generator step, if any
  • whether required unit tests could be added
  • whether CTest integration succeeded
  • whether validation-container test execution succeeded
  • whether Jenkins CI discovery/execution support succeeded
  • whether required forward declarations were added under ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/forward-declarations
  • exact reason if three tests per C++ change were not feasible

Final Report

Keep the final report short and factual.

Report:

  • status: validated, partially validated, or blocked
  • services migrated:
    • Lts/ScreenRecording
    • Lts/ServiceManagement
    • Lts/ServiceMonitor
    • Lts/SituationMap
    • Lts/SituationReplay
    • Lts/SituationReplayManagement
    • Lts/SoundManagement
  • services already migrated, if any
  • services not migrated and why, if any
  • root causes fixed
  • files changed
  • C++ files changed
  • forward declaration files changed under ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/forward-declarations
  • number of unit tests added per C++ change
  • test files changed
  • CTest registration changes
  • validation-container changes for test execution
  • Jenkins CI changes in ./qt-migration-legatus/ci/Dockerfile.* or ./qt-migration-legatus/ci/check_pr_policies.py
  • CMake changes made
  • generator changes made
  • Qt5:: references removed or remaining
  • confirmation that removed modules from 92ad7d468 were not restored
  • confirmation that LogViewer from 1fa789767 was preserved
  • confirmation that RoutingServiceNG migration rules were followed
  • whether RTI/codegen/KTextTemplate was involved
  • whether generation timing was correct
  • whether output placement remained build-tree only
  • exact Docker/build commands used
  • result of BUILD_RTI=OFF ./docker_build.sh
  • result of BUILD_RTI=ON ./docker_build.sh if run
  • result of ctest in the validated build directories
  • result of ./docker-build.h if present
  • remaining failures, blockers, or risks
Reference in new issue View Git Blame Copy Permalink