ci(vcpkg): skip Release for x64-windows-meshlib-iterator-debug triplet

[Fedr]

Summary

The x64-windows-meshlib-iterator-debug triplet is consumed by exactly one matrix cell — the Debug-IteratorDebug build defined in .github/workflows/matrix/windows-*-config.json, which is configured as Debug and links only the Debug variant of vcpkg ports. Yet prepare-images.yml's windows-vcpkg-build-upload job invokes thirdparty\install.bat for that triplet without any build-type narrowing, so vcpkg builds and uploads both the Debug and the Release variants to s3://vcpkg-export/<tag>/x64-windows-meshlib-iterator-debug/. The Release half is never read.

Setting VCPKG_BUILD_TYPE=debug in the triplet tells vcpkg to skip Release. Cache paths are partitioned by triplet (install.bat builds the S3 prefix from VCPKG_DEFAULT_TRIPLET), so the x64-windows-meshlib Release cache used by Release consumers is unaffected.

While here, also drop the redundant

set(VCPKG_CMAKE_CONFIGURE_OPTIONS "${VCPKG_CMAKE_CONFIGURE_OPTIONS} -T v142")

line — VCPKG_PLATFORM_TOOLSET "v142" two lines above already pins the toolset.

Cache busting

The triplet file content is hashed into both the S3 ABI hash and the GitHub Actions cache key (hashFiles(..., 'thirdparty/vcpkg/triplets/{triplet}.cmake', ...) in setup-vcpkg-windows/action.yml). The next prepare-images run with this triplet will rebuild from source once and repopulate; subsequent consumer runs get cache hits as usual.

Host-tools note

install.bat passes --host-triplet %VCPKG_DEFAULT_TRIPLET%, so any port-build host tools for the iterator-debug triplet would also be debug-only. The packages in requirements/windows.txt are all libraries (boost, eigen, opencascade, openvdb, etc.) — none ship heavy host compilers — so this should just be a slightly slower one-time port-build, not a breakage.

Test plan

• prepare-images.yml with windows-vcpkg-rebuild triggered: windows-vcpkg-build-upload (x64-windows-meshlib-iterator-debug) job finishes, S3 cache under s3://vcpkg-export/<tag>/x64-windows-meshlib-iterator-debug/ contains Debug archives only
• Downstream Debug-IteratorDebug consumer (windows-2025, msvc-2019, Debug config) restores cache and links successfully
• No Release-config consumer regresses (they continue to use the unchanged x64-windows-meshlib triplet cache)

[Fedr]

Closing — VCPKG_BUILD_TYPE=debug isn't viable for this triplet.

The first failed CI run (job 74138061869) hit a hard incompatibility: lz4's portfile calls vcpkg_replace_string against the Release-located header ${CURRENT_PACKAGES_DIR}/include/lz4.h after vcpkg_cmake_install() (ports/lz4/portfile.cmake:40). With VCPKG_BUILD_TYPE=debug only the Debug install step runs, so headers land under debug/include/ and the Release path doesn't exist.

This is a generic vcpkg-port problem, not specific to lz4: VCPKG_BUILD_TYPE=release is well supported across upstream ports, but VCPKG_BUILD_TYPE=debug isn't — many portfiles post-process Release-located artifacts unconditionally. lz4 was just the first failure; gdcm/opencascade/openvdb/etc. would likely surface the same pattern. Carrying overlay-port patches per failing port adds ongoing maintenance whenever those ports are bumped, and prepare-images.yml's windows-vcpkg-build-upload only runs on vcpkg version bumps (gated by need_windows_vcpkg_rebuild), so the wasted Release-half builds on this triplet are infrequent enough that the maintenance cost outweighs the savings.

Branch HEAD preserved at tag wip/iterator-debug-skip-release-pr-6031 in case we want to revisit (e.g. via upstream patches that guard post-install steps with if(NOT VCPKG_BUILD_TYPE STREQUAL "debug")).