ci(build): Add MinGW-w64 i686 cross-compilation to CI workflow

[JohnsterID]

Add automated MinGW-w64 (i686) build jobs for both Generals and GeneralsMD to the CI pipeline, enabling Linux-hosted cross-compilation with artifact collection matching the MSVC PDB workflow.

Changes:

• .github/workflows/ci.yml: Add two new matrix build jobs
  • build-mingw-generals: Builds Generals with mingw-w64-i686 toolchain
  • build-mingw-generalsmd: Builds GeneralsMD with mingw-w64-i686 toolchain
  • Matrix: mingw-w64-i686 (Release), mingw-w64-i686-debug (Debug)
  • Profile preset excluded (uses MSVC inline ASM with no GCC equivalent)

Toolchain setup (ubuntu-latest):

• MinGW-w64 cross-compiler (i686-w64-mingw32-gcc)
• Wine stable + widl for COM interface compilation
• CMake with Unix Makefiles generator
• Cached toolchain and dependencies

Artifact collection:

• Stripped executable (.exe) + separate debug symbols (.exe.debug) for Release
• Single executable with embedded symbols for Debug
• Matches MSVC .exe + .pdb workflow
• Static linked (no DLL dependencies)
• 30-day retention period

Jobs respect detect-changes filter (Generals/, GeneralsMD/, Core/, .github/workflows/, etc.) for conditional execution, identical to existing VC6 and win32 build triggers.

Result: 4 new artifact combinations

• Generals-mingw-w64-i686 (76 MB: 12 MB exe + 229 MB debug)
• Generals-mingw-w64-i686-debug (56.6 MB: 200 MB exe)
• GeneralsMD-mingw-w64-i686 (82.2 MB: 13 MB exe + 248 MB debug)
• GeneralsMD-mingw-w64-i686-debug (61.4 MB: 215 MB exe)

Runtime issues

• Fix MinGW-w64 import library symbol decoration bink-sdk-stub#7
• Add MinGW-w64 import library symbol decoration fix miles-sdk-stub#10
  - Also note TheSuperHackers/bink-sdk-stub@3241ee1 breaks VS building, see INSTALL target is broken by Bink Update #2166 so bink cmake needs review Fixed by Prevent install target generation if not top level. bink-sdk-stub#8

Closes #486

[greptile-apps]

Greptile Summary

This PR adds two new CI jobs (build-mingw-generals and build-mingw-generalsmd) that cross-compile the game executables on ubuntu-latest using the MinGW-w64 i686 toolchain, producing stripped release and debug artifacts that mirror the existing MSVC PDB workflow. The jobs integrate cleanly with the existing detect-changes filter and artifact retention policy.

Key observations:

• The cache key pattern in both jobs (cmake-deps-mingw-${{ matrix.preset }}-...) is identical, causing a race-to-save collision when the two jobs run in parallel with the same preset; adding a per-job discriminator to the key prevents silent cache conflicts.
• The 20-line "Install Wine and widl" shell block is duplicated verbatim between the two jobs; extracting this into a composite action or reusable workflow step would make future maintenance safer.

Confidence Score: 3/5

• Safe to merge with minor rework on cache key discriminators and Wine setup consolidation.
• The new jobs follow the same structure as existing CI jobs and integrate correctly with the change-detection filter. The cache key collision is a real but low-severity issue — it won't break builds today since both jobs fetch the same upstream dependencies, but it is logically incorrect and could silently cause problems if dependency sets ever diverge. The duplicated Wine installation block is a maintainability concern. Neither issue prevents the builds from working correctly.
• .github/workflows/ci.yml — cache key collision on lines 225–230 and 313–318 needs a per-job discriminator; Wine installation block (lines 203–223) is duplicated at lines 291–311.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[push / PR / workflow_dispatch] --> B[detect-changes]
    B -->|generals or shared changed| C[build-mingw-generals]
    B -->|generalsmd or shared changed| D[build-mingw-generalsmd]

    C --> C1[Checkout Code]
    C1 --> C2[Install MinGW-w64 Toolchain]
    C2 --> C3[Install Wine and widl]
    C3 --> C4[Cache CMake Dependencies]
    C4 --> C5[cmake configure - Generals preset]
    C5 --> C6[cmake build - target g_generals]
    C6 --> C7[Collect Artifacts - exe / dll / exe.debug]
    C7 --> C8[Upload Artifact - Generals-preset - 30 days]

    D --> D1[Checkout Code]
    D1 --> D2[Install MinGW-w64 Toolchain]
    D2 --> D3[Install Wine and widl]
    D3 --> D4[Cache CMake Dependencies]
    D4 --> D5[cmake configure - GeneralsMD preset]
    D5 --> D6[cmake build - target z_generals]
    D6 --> D7[Collect Artifacts - exe / dll / exe.debug]
    D7 --> D8[Upload Artifact - GeneralsMD-preset - 30 days]

    C4 -.->|cache key collision for same preset| D4

Loading

_{Last reviewed commit: 639c907}

[xezon]

How do these sizes compare with the other builds that we do?

[jurassicLizard]

How do these sizes compare with the other builds that we do?

mingw binaries are almost always larger as these builds have a lot of statically linked libraries most notably libgcc and libstdc++ which could be dynamically linked dlls and shipped seperately to reduce size if it is a concern

[JohnsterID]

Yep, this is a trade-off: ease of use and portability/convenience versus size. These builds prioritize self-contained artifacts over minimizing footprint.

[xezon]

@JohnsterID can you Rebase this to see if it still compiles?

[greptile-apps]

Cache key collision between concurrent jobs: both build-mingw-generals and build-mingw-generalsmd produce identical cache keys for matching preset values (e.g., both output cmake-deps-mingw-mingw-w64-i686-<hash>). When these jobs run in parallel, whichever finishes first wins the single cache slot; the other job's save is silently dropped.

While the CMake dependencies are likely identical today, the pattern is fragile. If Generals and GeneralsMD ever require different sub-dependencies, one job will silently restore the wrong cached tree. Add a job-specific discriminator to the cache key to eliminate ambiguity — for example, use cmake-deps-mingw-generals-${{ matrix.preset }}-... in build-mingw-generals and cmake-deps-mingw-generalsmd-${{ matrix.preset }}-... in build-mingw-generalsmd.

The same collision exists in build-mingw-generalsmd at line 313–318.

Prompt To Fix With AI

This is a comment left during a code review.
Path: .github/workflows/ci.yml
Line: 225-230

Comment:
Cache key collision between concurrent jobs: both `build-mingw-generals` and `build-mingw-generalsmd` produce identical cache keys for matching preset values (e.g., both output `cmake-deps-mingw-mingw-w64-i686-<hash>`). When these jobs run in parallel, whichever finishes first wins the single cache slot; the other job's save is silently dropped.

While the CMake dependencies are likely identical today, the pattern is fragile. If Generals and GeneralsMD ever require different sub-dependencies, one job will silently restore the wrong cached tree. Add a job-specific discriminator to the cache key to eliminate ambiguity — for example, use `cmake-deps-mingw-generals-${{ matrix.preset }}-...` in `build-mingw-generals` and `cmake-deps-mingw-generalsmd-${{ matrix.preset }}-...` in `build-mingw-generalsmd`.

The same collision exists in `build-mingw-generalsmd` at line 313–318.

How can I resolve this? If you propose a fix, please make it concise.

[xezon]

Ok every target is building. Are we happy to merge this now or is there still something to do?

[tintinhamans]

Changed title to ci(build) as this change is about CI primarily, not build like e.g. a CMake change would be.