153 lines
7.2 KiB
Plaintext
153 lines
7.2 KiB
Plaintext
Migrate the legacy Qt5/C++11 desktop application to Qt6/C++23 and validate the migration completely using the repository’s Docker-based CI workflow.
|
||
|
||
Operating mode:
|
||
- Execute the task autonomously from analysis through validation.
|
||
- Do not stop after code edits; continue until configure, build, tests, and policy checks have been attempted in the CI container workflow.
|
||
- Do not ask for confirmation between normal implementation steps.
|
||
- Only stop early if the repository is missing required source material, the task is logically impossible, or a destructive action would be required.
|
||
|
||
Project boundaries:
|
||
- Read the legacy source project from ${PROJECT_DIR}.
|
||
- Write the migrated project into qt6-after/qt6-migrated-benchmark.
|
||
- Do not modify the legacy source tree in place.
|
||
- Keep the migration isolated to the target tree and related CI/build/test files only when necessary.
|
||
|
||
Primary migration goals:
|
||
- Update the build system from Qt5 to Qt6.
|
||
- Upgrade the language standard from C++11 to C++23.
|
||
- Keep Qt Core, Gui, and Widgets explicitly linked.
|
||
- Replace QRegExp with QRegularExpression.
|
||
- Replace QDesktopWidget and QApplication::desktop() usage with QScreen-based Qt6 APIs.
|
||
- Remove legacy QTextCodec usage and adopt modern Qt6-safe text handling.
|
||
- Replace old SIGNAL/SLOT syntax with function-pointer connect syntax.
|
||
- Replace legacy null pointer literals with nullptr.
|
||
- Preserve .ui integration.
|
||
- Preserve .qrc integration.
|
||
- Preserve application behavior unless a Qt6-compatible adaptation is strictly necessary.
|
||
|
||
Testing requirements:
|
||
- For every code change inside a method, add at least three tests covering the changed behavior.
|
||
- Place all generated tests in qt6-after/qt6-migrated-benchmark/tests.
|
||
- Keep test filenames compatible with repository policy checks, for example patterns like:
|
||
- test_<name>.cpp
|
||
- <name>_test.cpp
|
||
- <name>test.cpp
|
||
- <name>gtest.cpp
|
||
- Update CMake so the migrated application and all tests are buildable and runnable with CTest.
|
||
- Ensure tests are actually registered with CTest.
|
||
|
||
Container-first build policy:
|
||
- Use lifemaps/ci-cpp:latest as the authoritative environment for configure, build, test, and policy validation.
|
||
- Do not rely on host-installed build tools as a substitute for missing container tools.
|
||
- Execute all validation commands inside Docker using the mounted repository workspace.
|
||
- Treat Dockerfile.ci as the source of truth for CI dependencies and container tool availability.
|
||
|
||
Execution plan:
|
||
1. Inspect the legacy project under ${PROJECT_DIR}.
|
||
2. Inspect the target tree qt6-after/qt6-migrated-benchmark.
|
||
3. Identify all Qt5/C++11 constructs that must be migrated.
|
||
4. Apply the migration incrementally in the target tree.
|
||
5. Add or update tests together with each behavior-relevant code change.
|
||
6. Update CMake and test registration.
|
||
7. Validate inside the Docker container.
|
||
8. If validation reveals missing tools inside the container, update Dockerfile.ci, rebuild the image, and rerun validation.
|
||
9. Repeat until full success or until a genuine project defect remains.
|
||
|
||
Mandatory container validation sequence:
|
||
- Run CMake configure inside lifemaps/ci-cpp:latest.
|
||
- Run the build inside lifemaps/ci-cpp:latest.
|
||
- Run tests with CTest inside lifemaps/ci-cpp:latest.
|
||
- Only if tests succeed, run:
|
||
python3 ci/check_pr_policies.py
|
||
inside the same Docker container against the mounted workspace.
|
||
|
||
Missing-tool remediation loop:
|
||
- If configure, build, test, or policy validation fails because a required tool or package is missing in the container:
|
||
- identify the missing tool precisely
|
||
- update Dockerfile.ci to install it
|
||
- rebuild the Docker image
|
||
- rerun the full validation sequence in the rebuilt image
|
||
- Do not stop after rebuilding once if another missing dependency appears.
|
||
- Continue until:
|
||
- the environment is complete and the next failure is a real project/code issue, or
|
||
- the entire validation flow succeeds
|
||
|
||
Failure classification rules:
|
||
- Treat these as environment failures:
|
||
- command not found
|
||
- missing compiler/toolchain utility
|
||
- missing Qt development package
|
||
- missing CMake/Ninja/CTest support tool
|
||
- missing formatting or git verification dependency needed by ci/check_pr_policies.py
|
||
- Treat these as project failures:
|
||
- compile errors in migrated source
|
||
- linker errors caused by project configuration or code
|
||
- failing tests
|
||
- policy check failures caused by formatting, missing tests, or related project issues introduced by the migration
|
||
|
||
Policy-check awareness:
|
||
- The repository policy script checks changed C/C++ files for formatting via clang-format.
|
||
- The policy script also expects related tests for changed C/C++ files.
|
||
- The policy script verifies commit signatures in its comparison range.
|
||
- When running local validation in the container, ensure the workspace and git metadata are available so the script can evaluate diffs properly.
|
||
- If the script fails because of issues caused by your migration, fix them and rerun validation.
|
||
- Do not claim policy success unless the script passes.
|
||
|
||
Container command expectations:
|
||
- Use Docker commands that mount the current repository into /workspace or an equivalent work directory.
|
||
- Run commands from the mounted repository root.
|
||
- Use explicit configure/build/test commands rather than vague summaries.
|
||
- Reuse the same image name lifemaps/ci-cpp:latest unless Dockerfile.ci changes require rebuilding that image.
|
||
|
||
Recommended validation shape:
|
||
- Configure:
|
||
cmake -S qt6-after/qt6-migrated-benchmark -B build -G Ninja -DCMAKE_BUILD_TYPE=Debug
|
||
- Build:
|
||
cmake --build build --parallel
|
||
- Test:
|
||
ctest --test-dir build --output-on-failure
|
||
- Policy:
|
||
python3 ci/check_pr_policies.py
|
||
- If the repository uses a different build directory or requires additional flags discovered during inspection, adapt accordingly.
|
||
|
||
Dockerfile maintenance rules:
|
||
- If you modify Dockerfile.ci, keep changes minimal and focused on missing CI dependencies.
|
||
- Do not remove already needed packages without evidence.
|
||
- After editing Dockerfile.ci, rebuild the CI image before retrying validation.
|
||
- Use the rebuilt image for all subsequent validation attempts.
|
||
|
||
Change reporting requirements:
|
||
- Briefly explain each migration change.
|
||
- Group the explanation by:
|
||
- CMake / build-system migration
|
||
- Qt API replacements
|
||
- C++ modernization
|
||
- UI/resource preservation
|
||
- tests added
|
||
- Dockerfile.ci / container updates
|
||
- Include a concise changed-files summary.
|
||
|
||
Completion criteria:
|
||
- Success requires all of the following:
|
||
- migrated project exists under qt6-after/qt6-migrated-benchmark
|
||
- configure succeeds in the Docker container
|
||
- build succeeds in the Docker container
|
||
- tests succeed in the Docker container
|
||
- python3 ci/check_pr_policies.py succeeds in the Docker container after tests pass
|
||
- If full success is not achieved, continue until the remaining blocker is a genuine project problem rather than a missing CI dependency.
|
||
|
||
Final response requirements:
|
||
- State whether the migration is fully validated or which blocker remains.
|
||
- List the exact Docker commands used for:
|
||
- image rebuild
|
||
- configure
|
||
- build
|
||
- test
|
||
- policy check
|
||
- For every failed attempt, report:
|
||
- the exact command
|
||
- the key error
|
||
- whether it was an environment issue or a project issue
|
||
- the fix applied, if any
|
||
- End with a short summary of what remains, if anything.
|