build(vcpkg): Define FFmpeg as VCPKG feature, disabled by default

[tsunamistate]

Closes #3175

• Defined FFMPEG as a VCPKG feature, disabled by default
• Removed RTS_BUILD_OPTION_FFMPEG from config-build.cmake, defining it in the top-level CMakeLists.txt before the project block

Testing:

1. Clear build folder
2. Configure the win32-vcpkg preset - cmake --preset win32-vcpkg. Note that FFMPEG is NOT built during vcpkg install.
3. Build the project - cmake --build --preset win32-vcpkg
4. Configure the win32-vcpkg preset with FFMPEG support - cmake --preset win32-vcpkg -DRTS_BUILD_OPTION_FFMPEG=ON
5. Build the project with FFMPEG support - cmake --build --preset win32-vcpkg. FFMPEG is built during the vcpkg install, FFMPEG DLLs are copied to the build folder
6. Optionally, move or remove BINKW32.DLL from the build folder of FFMPEG support build and launch the game to test if cutscenes still work

No LLMs were used during the creation of this PR

RTFM used:

• https://learn.microsoft.com/en-us/vcpkg/concepts/features
• https://learn.microsoft.com/en-us/vcpkg/users/buildsystems/cmake-integration#vcpkg_manifest_features

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Make FFmpeg an optional vcpkg feature (default off)

✨ Enhancement ⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Make FFmpeg an opt-in vcpkg manifest feature to avoid default builds.
• Add a CMake option that toggles the vcpkg feature during configure.
• Move FFmpeg build option definition to top-level CMake before project().

Diagram

graph TD
  A["Developer/CI"] --> B["CMake configure"] --> C["CMakeLists.txt option"] --> D["VCPKG_MANIFEST_FEATURES"] --> E["vcpkg.json features"] --> F["vcpkg install"] --> G["FFmpeg port"]

  subgraph Legend
    direction LR
    _usr["Actor/Invoker"] ~~~ _cfg["Config file"] ~~~ _dep[("Dependency")]
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Set VCPKG_MANIFEST_FEATURES only in CMakePresets/CI

• ➕ Avoids adding a project-level CMake option just for vcpkg integration
• ➕ Keeps feature selection closer to environment/preset definitions
• ➖ Less discoverable for developers configuring manually
• ➖ Harder to document a single toggle that works across generators/IDEs

2. Use separate manifests (vcpkg.json vs vcpkg-ffmpeg.json)

• ➕ Very explicit dependency sets; no conditional feature wiring
• ➕ Can simplify mental model for packagers
• ➖ More files to maintain; risk of drift between manifests
• ➖ Requires extra tooling/preset logic to pick the right manifest

Recommendation: The PR’s approach (optional vcpkg feature + a CMake toggle that appends to VCPKG_MANIFEST_FEATURES) is the best default here: it keeps FFmpeg off by default to speed installs, while providing a discoverable, single-switch opt-in path that works in IDE-driven CMake flows.

Files changed (3) +19 / -9

Other (3) +19 / -9

CMakeLists.txtAdd RTS_BUILD_OPTION_FFMPEG and enable vcpkg feature when ON +6/-0

Add RTS_BUILD_OPTION_FFMPEG and enable vcpkg feature when ON

• Defines RTS_BUILD_OPTION_FFMPEG before the project() block and, when enabled, appends "ffmpeg" to VCPKG_MANIFEST_FEATURES so vcpkg installs FFmpeg only on demand.

CMakeLists.txt

config-build.cmakeRemove duplicate RTS_BUILD_OPTION_FFMPEG option definition +0/-1

Remove duplicate RTS_BUILD_OPTION_FFMPEG option definition

• Drops RTS_BUILD_OPTION_FFMPEG from config-build.cmake now that it is defined at the top-level CMakeLists.txt to ensure it is available before project() and vcpkg feature selection.

cmake/config-build.cmake

vcpkg.jsonMake FFmpeg an opt-in vcpkg feature instead of a default dependency +13/-8

Make FFmpeg an opt-in vcpkg feature instead of a default dependency

• Removes ffmpeg from the base dependency list and introduces a new manifest feature "ffmpeg" that depends on the ffmpeg port, keeping default installs smaller unless the feature is enabled.

vcpkg.json

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

Tip of the day

💡 Did you know, you can copy the agent prompt from any finding and feed it to your IDE agent

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[bobtista]

This looks good to me - we should merge 2542 first, then rebase this - if this merges first, FFMPEG enabled cold builds may still be broken on the dead MSYS2 download.

We should probably set RTS_BUILD_OPTION_FFMPEG=ON in one GeneralsMD win32-vcpkg CI job, and let's keep it off by default in CMakePresets.

In your PR description for the manual testing instructions, I would use:

cmake --preset win32-vcpkg -DRTS_BUILD_OPTION_FFMPEG=ON
cmake --build --preset win32-vcpkg

[tsunamistate]

Updated test instructions to use the command line

[bobtista]

Can you set RTS_BUILD_OPTION_FFMPEG=ON in one GeneralsMD win32-vcpkg CI job?

[tsunamistate]

@bobtista I don't have a lot of experience with GitHub Actions setup, but I added an FFMPEG toggle and one additional job that is a clone of VCPKG release build with FFMPEG enabled.
Is that what you had in mind?

[bobtista]

@bobtista I don't have a lot of experience with GitHub Actions setup, but I added an FFMPEG toggle and one additional job that is a clone of VCPKG release build with FFMPEG enabled. Is that what you had in mind?

The workflow input and CMake look right, but it doesn't enable an FFmpeg CI build. The new matrix entry is commented out, and build-generalsmd-win32 does not pass the matrix value into the reusable workflow, so inputs.ffmpeg will still default to false.

After #2542 (already approved) merges and this is rebased, I would just add ffmpeg: true to the existing GeneralsMD win32-vcpkg release matrix entry rather than adding a duplicate job, then pass it through under with::
ffmpeg: ${{ matrix.ffmpeg || false }}
The other vcpkg jobs will continue testing the default-OFF path.

Also a nit:
change
${{ inputs.ffmpeg && '+ffmpeg'}}
to
${{ inputs.ffmpeg && '+ffmpeg' || '' }}

This could also be added to the reusable job name near the top of that file so the Actions job list identifies which build uses FFmpeg eg
name: ${{ inputs.preset }}${{ inputs.tools && '+t' || '' }}${{ inputs.extras && '+e' || '' }}${{ inputs.ffmpeg && '+ffmpeg' || '' }}

Just a nice to have, it matches the existing tools/extras pattern and avoids rendering a false value weirdly

[tsunamistate]

The new matrix entry is commented out, and build-generalsmd-win32 does not pass the matrix value into the reusable workflow, so inputs.ffmpeg will still default to false.

I assumed I would uncomment it after 2542 is merged

I would just add ffmpeg: true to the existing GeneralsMD win32-vcpkg release matrix entry rather than adding a duplicate job, then pass it through under with::
ffmpeg: ${{ matrix.ffmpeg || false }}

Done

Also a nit:
change
${{ inputs.ffmpeg && '+ffmpeg'}}
to
${{ inputs.ffmpeg && '+ffmpeg' || '' }}

Done

[tsunamistate]

Now, that #2542 is merged, rebased and resolved conflicts
cc @bobtista

[greptile-apps]

Greptile Summary

The PR makes FFmpeg an optional vcpkg feature that is disabled by default and enables it for one GeneralsMD CI configuration.

• Defines the FFmpeg option before CMake initializes the vcpkg toolchain.
• Moves FFmpeg from the default manifest dependencies into an opt-in manifest feature.
• Adds a typed reusable-workflow input and exercises the feature in the win32-vcpkg CI build.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
.github/workflows/ci.yml	Enables FFmpeg for the GeneralsMD win32-vcpkg matrix entry and passes a valid default-false boolean to the reusable workflow; the previously reported conflict markers are gone.
.github/workflows/build-toolchain.yml	Adds a typed FFmpeg input and translates it into the corresponding CMake option.
CMakeLists.txt	Loads vcpkg feature configuration before project() so manifest features are selected before toolchain initialization.
cmake/config-vcpkg.cmake	Defines the default-off FFmpeg build option and conditionally appends the matching vcpkg manifest feature.
vcpkg.json	Moves FFmpeg from unconditional dependencies into an optional named feature.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  CI[CI matrix ffmpeg flag] --> Input[Reusable workflow input]
  Input --> Option[RTS_BUILD_OPTION_FFMPEG]
  Option -->|ON| Feature[VCPKG_MANIFEST_FEATURES: ffmpeg]
  Feature --> Dependency[vcpkg installs FFmpeg]
  Option -->|OFF| Default[FFmpeg dependency omitted]

Loading

_{Reviews (9): Last reviewed commit: "Review feedback, round 2" | Re-trigger Greptile}

[tsunamistate]

Build fail was because I accidentally reverted the baseline commit change made in cc48d39, should be fine now

[bobtista]

I like the dedicated cmake/vcpkg.cmake suggestion, and let's leave cmake/config.cmake where it is and keep add_feature_info(FFmpegSupport ...) in config-build.cmake

[tsunamistate]

I like the dedicated cmake/vcpkg.cmake suggestion, and let's leave cmake/config.cmake where it is

Done

and keep add_feature_info(FFmpegSupport ...) in config-build.cmake

Why make a duplicate? It would only cause bugs

[bobtista]

I like the dedicated cmake/vcpkg.cmake suggestion, and let's leave cmake/config.cmake where it is

Done

and keep add_feature_info(FFmpegSupport ...) in config-build.cmake

Why make a duplicate? It would only cause bugs

Sorry I don't mean to suggest a duplicate - the current commit is exactly what I meant. The option(...) declaration lives in cmake/vcpkg.cmake, while the existing add_feature_info(...) remains in config-build.cmake to register it with feature_summary(). No further change needed.

[tsunamistate]

@xezon addressed your comments and rebased

[OmarAglan]

@codex

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Chef's kiss.

Reviewed commit: 85aa96165c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[xezon]

Looks fine