Fix Windows CI failure: make ableton-link an optional vcpkg feature

[Copilot]

Windows CI failed during vcpkg dependency configuration for ableton-link:x64-windows-csound, even though the workflow already passes -DBUILD_ABLETON_LINK_OPCODES=OFF to CMake.

Root cause: 6.x/vcpkg.json listed ableton-link as an unconditional manifest dependency. vcpkg installs all manifest dependencies as soon as its toolchain is invoked (at the CMake project() call), before BUILD_ABLETON_LINK_OPCODES is even evaluated — that option only gates add_subdirectory(./src/AbletonLinkOpcodes) later in the file. So disabling the opcode never stopped vcpkg from building the (currently broken) ableton-link port.

• 6.x/vcpkg.json: moved ableton-link from dependencies into an optional features entry.
• 6.x/CMakeLists.txt: added option(BUILD_ABLETON_LINK_OPCODES ...) ahead of the vcpkg toolchain setup, and only append "ableton-link" to VCPKG_MANIFEST_FEATURES when that option is ON — so vcpkg only attempts to install/build it when actually requested.
• .github/workflows/plugins_build.yml: added a verification step after CMake configure that checks build/vcpkg_installed and fails CI if ableton-link is present, guarding against this regression going forward.

"dependencies": ["eigen3", "fltk", ...],
"features": {
  "ableton-link": {
    "description": "Support for Ableton Link opcodes",
    "dependencies": ["ableton-link"]
  }
}

option(BUILD_ABLETON_LINK_OPCODES "Build Ableton Link Opcodes" OFF)

if (USE_VCPKG)
    if (BUILD_ABLETON_LINK_OPCODES)
        list(APPEND VCPKG_MANIFEST_FEATURES "ableton-link")
    endif()
    ...

[vlazzarini]

@copilot

CI Failure Diagnosis

I've investigated the Windows CI failure in job 99899315126. The immediate issue is a network/package availability problem unrelated to your changes:

Current failure: vcpkg is unable to download mingw-w64-i686-pkgconf-1~1.8.0-2-any.pkg.tar.zst from MSYS2 mirrors (all returning 404 errors). This occurs during vcpkg_fixup_pkgconfig() for the eigen3 port and is blocking the build before it reaches your ableton-link optional feature logic.

Why it matters for your PR: Your changes correctly move ableton-link to an optional feature, which is the right fix. However, the build isn't reaching the point where that logic is tested because vcpkg is failing earlier on a dependency resolution issue. This is a transient infrastructure issue, not a regression in your code.

Recommended next step: The CI will likely pass once vcpkg's package mirrors are updated or when the runner picks up a newer vcpkg version. You can either:

1. Trigger a re-run of the workflow to see if the MSYS2 mirrors recover, or
2. Add an explicit vcpkg update step in the workflow to ensure the latest port definitions are used

Your implementation looks solid — the current failure is environmental, not code-related.

[Copilot]

@copilot

CI Failure Diagnosis

...

Thanks for confirming the ableton-link fix works. Rather than just retrying, I added a deterministic fix in 2b1... (latest commit): the Windows setup step now installs pkgconfiglite via chocolatey and sets PKG_CONFIG to its path. vcpkg's vcpkg_find_acquire_program(PKGCONFIG) short-circuits its own MSYS2 download whenever PKG_CONFIG is already set, so eigen3's vcpkg_fixup_pkgconfig() call (and any other port needing pkg-config) no longer depends on that MSYS2 mirror at all.

[vlazzarini]

@copilot

The Windows CI job is failing with a vcpkg package download error, not due to your PR changes. The error occurs when eigen3's build process tries to download mingw-w64-i686-pkgconf-1~1.8.0-2-any.pkg.tar.zst from MSYS2 mirrors — all mirrors return 404 because this specific package version is no longer available.

Your changes to make ableton-link optional are correct and unrelated to this failure. However, to get the CI to pass, the workflow needs to update vcpkg before running CMake configuration. Add this step to .github/workflows/plugins_build.yml after line 52 (the bootstrap-vcpkg.bat call):

- name: Update vcpkg
  shell: bash
  run: |
    cd 6.x/vcpkg
    git pull
    ./vcpkg update

This refreshes the port definitions so vcpkg can request package versions that are currently available on the mirrors.

@copilot action?

[Copilot]

@copilot

The Windows CI job is failing with a vcpkg package download error, not due to your PR changes. The error occurs when eigen3's build process tries to download `mingw-w64-i686-pkgconf-1...

I looked at the actual failing run more closely: the previous PKG_CONFIG env var fix (from the chocolatey step) was set correctly, but eigen3 still tried the MSYS2 download. That's because vcpkg builds ports in a restricted/clean environment on Windows and only forwards env vars explicitly listed in a triplet's VCPKG_ENV_PASSTHROUGH (confirmed by vcpkg's own community mingw triplets, which must pass through even PATH). Our custom x64-windows-csound triplet had no such passthrough, so ENV{PKG_CONFIG} was never visible to the port build subprocess.

Fixed in 9abd28e by adding set(VCPKG_ENV_PASSTHROUGH PKG_CONFIG) to 6.x/x64-windows-csound.cmake, so the chocolatey pkg-config is now actually used and the MSYS2 download is skipped entirely — this is more reliable than git pull/vcpkg update, since the pinned baseline commit (and its 404'ing pkgconf URL) wouldn't otherwise change. A new CI run is queued on this commit; it currently needs a maintainer to approve/re-run it.

[vlazzarini]

@copilot CI continues to fail

Job 99913073750

[Copilot]

@copilot CI continues to fail

Job 99913073750

Looked at job 99913073750: the good news is ableton-link and the pkgconf/MSYS2 issue are both resolved — the build now progresses to 7/37 packages. It then fails on zlib with the exact same error signature as the original ableton-link failure (vcpkg_execute_required_process / ninja.exe -v during CMake configure).

The log shows -- Building for: Visual Studio 18 2026. Per GitHub's runner-images repo, windows-latest now provisions the "Windows Server 2025" image with Visual Studio 2026, which this repo's pinned vcpkg baseline doesn't support — that's the real root cause behind both the original ableton-link failure and now zlib, and it would keep recurring for other from-source ports too.

Fixed in e544db4 by pinning the workflow's runs-on/matrix to windows-2022 (still Visual Studio 2022, known-compatible with this vcpkg baseline) instead of windows-latest. A new CI run is queued on this commit; it needs a maintainer approval/re-run since it was pushed by the agent.

[vlazzarini]

@copilot this is not working. Can you rewrite the workflow to build for Windows MSVC only and remove the MSYS2 CI build completely?

[Copilot]

@copilot this is not working. Can you rewrite the workflow to build for Windows MSVC only and remove the MSYS2 CI build completely?

There's no separate MSYS2 job to remove — the workflow only ever has one matrix entry (windows-2022) and builds via the MSVC/Visual Studio generator, confirmed by -- Building for: Visual Studio 18 20xx in every log. MSYS2 only shows up as an implementation detail vcpkg uses internally to fetch a few Unix-style build tools (autoconf, automake, libtool, make, pkgconf) needed by upstream ports that use autotools even when producing MSVC-compatible libraries — specifically libiconv/gettext/glib (pulled in transitively by fluidsynth) and eigen3's pkg-config step.

I dug into job 99918038621 (windows-2022 run, got further than ever to 16/37 packages) and found the real root cause: this repo's 6.x/vcpkg submodule is pinned to a June 2023 snapshot (f6a5d4e8eb), and that exact vcpkg version's scripts hardcode specific MSYS2 package filenames (e.g. autoconf-wrapper-20221207-1-any.pkg.tar.zst, pkgconf-1~1.8.0-2). MSYS2 mirrors have since pruned those old versions (404s), so any port needing them fails, regardless of Windows image/compiler.

Fixed in 63187f9 by bumping the 6.x/vcpkg submodule to 9e593bb18e (tag 2026.07.29) and updating builtin-baseline in 6.x/vcpkg.json to match, so vcpkg requests currently-available MSYS2 package versions instead. Verified all 9 required ports still exist in the new vcpkg and that manifest/baseline resolution succeeds. A new CI run is queued on this commit; it needs a maintainer approval/re-run.

[vlazzarini]

@copilot this continues to fail, see build 99931632108

we need a working CI. If the problem is with Windows and VCPKG, replace it by a Linux/Ubuntu build that works.

[Copilot]

@copilot this continues to fail, see build 99931632108

we need a working CI. If the problem is with Windows and VCPKG, replace it by a Linux/Ubuntu build that works.

Good news: build 99931632108 shows the vcpkg/MSYS2 problem from before is actually fixed — all 33 vcpkg packages (including the ones that previously failed: ableton-link, eigen3/pkgconf, zlib, libiconv) installed successfully after the submodule bump. So a Linux rewrite isn't needed for that part; the current failure is a completely separate, unrelated issue further down the pipeline.

The build now fails at find_package(CSOUND) with "Csound header files are required". Root cause: CSOUND_INCLUDE_DIR_HINT in 6.x/CMakeLists.txt was hardcoded to the legacy path C:/Program Files/Csound6_x64, but CI's choco install csound now deploys to C:/Program Files/csound (confirmed in the job log: Deployed to 'C:\Program Files\csound\'), so CMake couldn't locate csound.h.

Fixed in 4e549a3 by pointing CSOUND_INCLUDE_DIR_HINT/CSOUND_LIBRARY_DIR_HINT at the choco layout (C:/Program Files/csound/include, C:/Program Files/csound/lib, matching csound's own install layout), keeping the old path as a fallback. A new CI run is queued on this commit; it needs a maintainer approval/re-run.

[vlazzarini]

@copilot it continues to fail, check job 99946922087

[Copilot]

@copilot it continues to fail, check job 99946922087

Looked at job 99946922087: vcpkg install and the CSOUND path fix both hold. Found two new hard CMake configure/generate errors further down the pipeline:

1. FAUST_INCLUDE_DIR-NOTFOUND used as an include directory — cmake/Modules/FindFAUST.cmake called find_package_handle_standard_args with the legacy 2-arg signature, so it only ever checked FAUST_LIBRARY, not FAUST_INCLUDE_DIR. Since this Windows runner's Faust installer doesn't ship the header at the hinted path, FAUST_FOUND was incorrectly TRUE with a NOTFOUND include dir, causing a hard failure.
2. hdf5::hdf5_hl-static target not found — vcpkg's hdf5 port only exports that target when its hl feature is requested, which 6.x/vcpkg.json wasn't doing.

Fixed in be414a5: use REQUIRED_VARS in FindFAUST.cmake (so BUILD_FAUST_OPCODES now gracefully disables like other optional opcodes instead of hard-failing), add the hl feature to hdf5 in vcpkg.json, and add skipifsourcedoesntexist to the installer's [Files] entries so it doesn't fail when an optional opcode isn't built. A new CI run is queued on this commit; it needs a maintainer approval/re-run.

[vlazzarini]

@copilot CI is still failing

[Copilot]

@copilot CI is still failing

Checked the latest run (job 99953288002, on be414a5): CMake configure/generate now succeed fully and the build progresses to actual compilation, but two new build/link errors surfaced:

1. src/hdf5/HDF5IO.c(235): error C2198: 'H5Oget_info3(...)': too few arguments — the version guard only routed to the compatible H5Oget_info1 call for HDF5 1.12.x, but this vcpkg baseline installs hdf5 2.1.1, where the plain H5Oget_info macro now expands to the 3-arg H5Oget_info3.
2. websocketIO: LINK1181: cannot open input file 'uv_a.lib' — the code links a bare uv_a target, but vcpkg's libuv CONFIG package now exports namespaced libuv::uv_a/libuv::uv targets.

Fixed in 32fa5db. A new CI run is queued on this commit; it needs a maintainer approval/re-run.

[vlazzarini]

@copilot CI failed one more time