ci(vcpkg): overlay zlib port with zlib-ng built in compat mode by Fedr · Pull Request #5932 · MeshInspector/MeshLib

Fedr · 2026-04-19T08:41:35Z

What

MeshLib-specific vcpkg overlay port at thirdparty/vcpkg/ports/zlib that shadows the upstream zlib port. The overlay builds zlib-ng 2.3.3 with ZLIB_COMPAT=ON, producing on-disk layout identical to upstream zlib:

include/zlib.h, include/zconf.h
lib/libz.{so,dylib} / z.lib
lib/cmake/ZLIB/ZLIBConfig*.cmake (ZLIB::ZLIB target)
lib/pkgconfig/zlib.pc

Every vcpkg port that transitively depends on zlib (libzip, libpng, openvdb, gdcm, …) picks up zlib-ng at link time with no source or link-flag changes anywhere else. Output format stays standard deflate — HP 3D printer / OPC / 3MF interoperability is preserved.

thirdparty/install.bat passes --overlay-ports alongside the existing --overlay-triplets. The Rocky path already passes --overlay-ports=MeshLib/ports in docker/rockylinux8-vcpkgDockerfile, so no Dockerfile change is needed there.

Scope: vcpkg only

Ubuntu (apt libz), macOS (brew zlib), and Emscripten (emsdk USE_ZLIB=1) remain on stock zlib in this PR. Each of those paths needs a different mechanism (apt has no drop-in compat, brew's zlib-ng isn't compat-by-default, Emscripten would need an emsdk port change). A parallel PR #5959 covers MRMesh's own zlibCompressStream / zlibDecompressStream on every platform — this PR and #5959 are orthogonal and can both land.

Cache-key fix

The previous run on this PR got a vcpkg cache hit on the master-side key (vcpkg-cache-<VERSION>-<TRIPLET>) and reused a pre-overlay installed tree — vcpkg install saw every port as already-installed and built zero of this PR's overlay. Effect on measurement: Windows CompressSphereToZip numbers matched master's stock-zlib baseline (~1.2–1.4 s Release) while Linux-vcpkg in the same run correctly showed the zlib-ng speedup (~450 ms Release).

The cache key is now extended with a hashFiles() over thirdparty/vcpkg/ports/**, thirdparty/vcpkg/triplets/**, requirements/windows.txt, and thirdparty/install.bat, matching the fix from PR #5934. Any change to the overlay (including this PR adding it) now busts the cache and forces the overlay to actually build.

Risk notes

Version-pin sensitivity: overlay declares "version": "1.3.1" + "port-version": 100. Any >=1.3.1 constraint is satisfied; an ==1.3.1 pin would fail. I didn't find such a pin in current requirements.
zlib-ng compat ABI is battle-tested (Chromium, Intel ISA-L, Ubuntu 24.04's libz-ng2). Surprises at runtime are unlikely; link-time is where issues would surface, and CI on this PR is the validation.
Ports present in the overlay dir but not requested by requirements/windows.txt (clip, laz-perf, opencascade-minimal, openctm) won't activate on Windows because Windows doesn't request them. --overlay-ports only preempts when the port name is requested, directly or transitively.

Measurement on the next CI run

Comparison point is PR #5959's last run (feat/zlib-compress-stream-zlib-ng at run 24848209290), where CompressSphereToZip on Linux-vcpkg platforms showed ~2.4–2.7× speedup vs stock zlib:

Platform	stock zlib	zlib-ng (measured on #5959)
linux-vcpkg x64 Release Clang 20	1204 ms	446 ms
linux-vcpkg arm64 Release Clang 20	865 ms	358 ms

On this PR's cache-busted run, Windows msvc-2019 Release + msvc-2022 Release are expected to move from the stock-zlib baseline (~1.35 / 1.35 s) down to roughly the same 450–650 ms band that Linux-vcpkg and PR #5959's Windows legs already demonstrate. If that happens, the overlay is doing its job.

Rollback

Single-commit revert removes the overlay port directory and the install.bat --overlay-ports flag; all consumers fall back to upstream zlib without any other file changes. The cache-key hashFiles line is independently useful (see PR #5934 post-mortem) and can stay.

🤖 Generated with Claude Code

Adds a MeshLib-specific vcpkg overlay port `thirdparty/vcpkg/ports/zlib` that shadows the upstream `zlib` port. The overlay builds zlib-ng/zlib-ng 2.3.3 with `ZLIB_COMPAT=ON`, producing: include/zlib.h, include/zconf.h lib/libz.{so,dylib} / z.lib lib/cmake/ZLIB/ZLIBConfig*.cmake (target ZLIB::ZLIB) lib/pkgconfig/zlib.pc i.e. byte-layout-compatible with upstream zlib. Every vcpkg port that depends on `zlib` (libzip, libpng, openvdb, gdcm, ...) picks up the faster zlib-ng implementation at link time without source or link-flag changes downstream. Output format is standard deflate - HP 3D printer / OPC / 3MF compatibility is preserved, as are any other consumers of the .zip files MeshLib produces. thirdparty/install.bat (Windows) now passes `--overlay-ports` alongside the existing `--overlay-triplets`, matching the pattern rockylinux8- vcpkgDockerfile already uses. Rocky side needs no change - its Dockerfile already does `--overlay-ports=MeshLib/ports`. Scope deliberately limited to vcpkg (Windows + Rocky). Ubuntu (apt libz), macOS (brew zlib), and Emscripten (emsdk --use-port=zlib) are left on stock zlib for this PR. Those paths would each need separate mechanism changes (apt can't swap libz in place; brew's zlib-ng formula doesn't install compat symbols by default; Emscripten would need a new submodule replacing -s USE_ZLIB=1) and deserve independent measurement. Follow-ups if vcpkg measurement is positive. Risk notes: - Some vcpkg ports may declare version constraints on `zlib`. The overlay keeps "version": "1.3.1" with "port-version": 100, so any `>=1.3.1` constraint is satisfied. A `==1.3.1` pin would fail on port-version mismatch; none known in current requirements. - Upstream zlib-ng compat mode is battle-tested (used in production by Intel ISA-L, Chromium, ...), but the first build via this overlay is the validation step. CI on this PR is the test. Measurement status: NOT measured. CI on this PR is the proof. Compare image init times AND compression-time-dependent job step timings (e.g., linux-vcpkg artifacts packaging) against master.

Creates a sphere with ~100K vertices, saves it as a .mrmesh file in a temporary folder, then calls compressZip to produce a .zip archive in a second temporary folder. Verifies: - mesh and zip files both exist and are non-empty - the zip is not absurdly larger than the source (envelope sanity) Serves as a realistic end-to-end exercise of MeshLib's zip write path (libzip + zlib deflate) against mesh-sized data. Suitable for timing comparisons of different zlib backends (e.g., stock zlib vs zlib-ng compat) when added to a run's measurement targets. Placed in source/MRTest/ as MRZipCompressTests.cpp; no CMake changes needed (the existing file(GLOB SOURCES "*.cpp") picks it up).

The Windows vcpkg cache key was only keyed by matrix.vcpkg-version, so changes to: - thirdparty/vcpkg/ports/** (MeshLib's overlay ports) - thirdparty/vcpkg/triplets/** - requirements/windows.txt - thirdparty/install.bat didn't invalidate the cache. A pre-built C:\vcpkg\installed\ tree was restored verbatim and install.bat's "vcpkg install ..." saw every port as "already installed" (total install time: 3.57 ms in the last PR run), so overlay ports never got consulted. Concrete symptom observed on PR #5932 (zlib → zlib-ng-compat overlay): - Linux-vcpkg (which rebuilds vcpkg inside a Docker image every time `prepare-image / linux-vcpkg-build-upload` runs) picked up zlib-ng; compression tests showed -0.3% zip size and -41 to -45% wall time on Release builds. - Windows vcpkg served the cached pre-zlib-ng tree; zip sizes and test times were indistinguishable from master. Fix: include a hashFiles() of the overlay/triplet/requirements/ install-script content in the cache key. First run after merging this takes the full ~20 min vcpkg install; subsequent runs hit the cache again as before.

… ci/libzip-zlib-ng-vcpkg

Observed in run 24638998286: on Windows, a fresh install of our zlib overlay (triggered by PR #5934 busting the vcpkg cache key) failed with: error: building zlib:x64-windows-meshlib failed with: BUILD_FAILED Missing msys2-mingw-w64-x86_64-pkgconf-1~2.2.0-1-any.pkg.tar.zst ... 404 from every msys2 mirror Root cause: our portfile called vcpkg_fixup_pkgconfig(), which on Windows invokes vcpkg_acquire_msys to download the pinned mingw-w64-pkgconf package from msys2 mirrors. That particular version has been pruned from the live mirrors; every one of the six fallback URLs 404s. Deterministic failure that re-runs won't fix. The call is not needed by our consumers. Every MeshLib/vcpkg consumer that depends on zlib finds it via the CMake target `ZLIB::ZLIB` exported from lib/cmake/ZLIB/ZLIBConfig.cmake; nobody reads lib/pkgconfig/zlib.pc via pkg-config. The .pc file is still generated by zlib-ng's own CMake, with a correct `Libs: -lz` entry in compat mode - it just doesn't get post-processed. Removing the call sidesteps the msys2 dependency entirely. zlib-ng-compat build steps (cmake configure, cmake install, copy_pdbs, cmake_config_fixup for ZLIB, copyright install) are unaffected.

One-line change to .github/workflows/build-test-windows.yml: append a unique suffix to the vcpkg cache key so the existing cached C:\vcpkg\installed\ tree is not restored. vcpkg reinstalls every port from scratch; upstream blosc's vcpkg_fixup_pkgconfig() tries to fetch mingw-w64-x86_64-pkgconf-1~2.2.0-1-any.pkg.tar.zst from msys2 mirrors, gets 404 on all six, and fails the Windows build. This is the same failure first seen on PR #5932 after PR #5934 (which adds the path-based cache busting in a principled way) exposed it. Master itself doesn't fail because its Windows vcpkg cache is a hot hit every run. Purely a diagnostic PR. Do not merge.

thirdparty/vcpkg/downloads/ is already used by thirdparty/install.bat to pre-seed C:\vcpkg\downloads\ with msys2 .pkg.tar.zst archives that vcpkg pins by SHA512 but msys2 mirrors have rotated out of their live repos. This adds one more entry: msys2-mingw-w64-x86_64-pkgconf-1~2.2.0-1-any.pkg.tar.zst SHA512 eb6ba49d56b0edc4f605ad896ac9deb2202c853c821f1c28a26e3c71a5083e893c 8697d174b141da9dc6561620ea218166bd041664d54a0ab51b93bad246ed7a Pinned by vcpkg 2024.10.21's scripts/cmake/vcpkg_find_acquire_program(PKGCONFIG).cmake. vcpkg checks local downloads/ first: if the file exists and its SHA512 matches, the network fetch is skipped. msys2 mirrors currently serve a newer -N suffix build of the same 2.2.0 upstream, so every pinned URL returns 404; this workaround unblocks any port that rebuilds from source and calls vcpkg_fixup_pkgconfig() (blosc, freetype, libharu, ...). Note: vcpkg 2026.03.18 (used by the msvc-2022 matrix entries) pins a completely different URL (pkgconf-2.5.1-1 from the msys repo, still available); that matrix entry is not affected and no file is needed for it. This fix is scoped to the 2024.10.21 / msvc-2019 path. Alternative long-term fix is to bump matrix.vcpkg-version off 2024.10.21. That's a bigger change with wider blast radius; this PR is the minimal targeted workaround.

…-staged Commit cb1edb5 dropped the vcpkg_fixup_pkgconfig() call from the overlay portfile to work around the msys2 pkgconf 1~2.2.0-1 404. That workaround broke Linux-vcpkg: the unrewritten lib/pkgconfig/zlib.pc left absolute build-tree paths (`-I/root/vcpkg/packages/zlib_x64-linux-meshlib/include`) baked into downstream pkg-config targets, so CMake's PkgConfig::curl imported target pointed at a directory that no longer existed at consumer time, producing: CMake Error in source/MRViewer/CMakeLists.txt: Imported target "PkgConfig::curl" includes non-existent path "/root/vcpkg/packages/zlib_x64-linux-meshlib/include" in its INTERFACE_INCLUDE_DIRECTORIES. Commit e250677 on this branch pre-stages the msys2 pkgconf archive vcpkg 2024.10.21 pins, so on Windows the vcpkg_acquire_msys() fetch inside vcpkg_fixup_pkgconfig() now hits the local file and succeeds instead of 404ing. vcpkg 2026.03.18 pins a different pkgconf build that's still live on msys2 mirrors. Both platforms therefore tolerate an unconditional vcpkg_fixup_pkgconfig() call again. Restore it so Linux-vcpkg gets the `.pc` rewriting it needs.

New GTest case MRMesh.CompressManySmallFilesToZip writes 100 binary files and 100 JSON files to a temp folder (each 60 000 bytes, 12 000 000 bytes total — matching the sphere.mrmesh size from the existing CompressSphereToZip test) and compresses the folder to a .zip. Binary file content is deterministic pseudo-random bytes from a per-index-seeded LCG — low-compressibility, representative of mesh coordinate floats and similar near-incompressible payloads. JSON file content is deterministic structured-looking text padded to exactly 60 000 bytes with trailing whitespace — highly compressible, representative of scene-description metadata and logs. Pairs with CompressSphereToZip so a single run of MRTest produces two direct data points: one-large-file vs many-small-files on roughly the same total byte budget. Useful for assessing libzip's per-entry overhead (separate deflate session, CRC pass, local file header) when comparing zlib backends or compression-level changes. Per-file byte count is constant and deterministic so the aggregate input size and zip size are stable across runs (modulo whatever small variation deflate itself introduces on different zlib builds). Logs totals via spdlog::info for easy diff with the other test.

Run 24670365594 on this branch hit the same msys2 mirror-404 class of failure we saw before, this time on a different pinned package: error: Missing msys2-msys2-runtime-3.5.3-3-x86_64.pkg.tar.zst and downloads are blocked by x-block-origin ...404 from all 6 mirrors error: building zlib:x64-windows-meshlib failed with: BUILD_FAILED Same mechanism, different file. vcpkg_acquire_msys() downloads an entire msys2 environment (bash, coreutils, file, gawk, grep, gzip, diffutils, make, pkgconf, sed — plus transitive deps like msys2-runtime), each pinned by SHA512 to a specific build. msys2 mirrors rotate old builds out of their live repos. We already pre-staged pkgconf in #5943; this commit adds the msys2-runtime file that failed next. File: msys2-msys2-runtime-3.5.3-3-x86_64.pkg.tar.zst SHA512: 35fd12556a53aa57d8f9500c5c98d5e1fc64c6fbba34cc97e2ff78893e5b1b63c 417bc1c8d1e62b26b2a93aef120fa1f9f82aad67dff4cc44af169d0d29d68f7 Matches the pin in vcpkg 2024.10.21's scripts/cmake/vcpkg_acquire_msys.cmake (line 444-445). thirdparty/install.bat copies thirdparty/vcpkg/downloads/ into C:\vcpkg\downloads\ before vcpkg install; vcpkg_download_distfile() checks the local file first and skips the network fetch if the SHA matches. Same caveat as with the pkgconf pre-staging: this is a point fix. vcpkg_acquire_msys() pulls several more packages that are equally exposed to msys2's retention policy; if any of those also fail in a future run, they will need the same treatment. A bigger fix (bump matrix.vcpkg-version off 2024.10.21 onto a release with still-live msys2 pins) is out of scope for this branch.

The previous push (db7e6c0) triggered a workflow event before skip-image-rebuild label was applied to this PR, so the current run (24680023870) rebuilt all images unnecessarily. This commit adds an empty marker comment so a new workflow event fires with the label in the event payload, gating off the three need_*_rebuild flags. Consumer jobs will pull the existing images pushed by the previous (successful) prepare-image run. Marker comment will be removed in a cleanup commit once CI confirms the skip path works.

The Build step used an `if errorlevel 1 exit 1` check after each command inside a parenthesized IF block in a cmd.exe batch script. On windows-2025 runners, that check was failing to catch `cmake --build` / ninja failures — observed in run 24691107383, msvc-2019 Release CMake: ninja reported ninja: build stopped: subcommand failed. (MRViewer.dll link failed with LNK1120 unresolved externals from cpr.lib), but the `if errorlevel 1 exit 1` after `cmake --build` didn't fire, so the script went on to `xcopy` and exited 0. GitHub Actions marked the step as `success` even though MRCuda.lib and other targets were never produced. The very next step, `Generate and build Python bindings`, tried to link `mrcudapy.pyd` against `MRCuda.lib` and failed with `lld-link: error: could not open 'MRCuda.lib': No such file or directory` — a confusing error 67 seconds after the real failure the step should have reported. `if errorlevel 1` inside parenthesized IF blocks in cmd.exe has well-known parse-time expansion quirks that can cause it to miss exit codes that were set by commands earlier in the same block. Replace the pattern with `|| exit /b 1` chained directly onto each command. `||` is evaluated at process-exit time and doesn't depend on errorlevel-in-parens semantics. This is the documented idiom for robust error propagation in cmd.exe batch files. Functional change: the step now fails fast with the first command's non-zero exit, instead of running to completion and reporting success regardless. Applies to all three Windows matrix entries (msvc-2019, msvc-2022 Debug, msvc-2022 Release). Does not change behavior when the build succeeds. Other steps in the same workflow (`Build MRBind`, `Generate C bindings`, `Generate and build Python bindings`) use similar cmd batch patterns and may have the same latent bug; left alone here to keep the PR scoped to the Build step that has a concrete reproducer. Worth auditing separately.

…into ci/libzip-zlib-ng-vcpkg

MRMesh.ZlibCompressStats pinned stats.compressedSize against the size of the stock-zlib reference blobs (cRawLevel9 / cWrappedLevel9). zlib-ng's deflate matcher emits 1-2 bytes less for the same input at the same level, which is a valid, lossless re-encoding but trips the equality check on any build that links zlib-ng instead of stock zlib (e.g. the macOS zlib-ng-compat swap in this PR, or the vcpkg zlib-ng overlay in #5932). Keep the engine-independent assertions (CRC-32, uncompressed size, internal consistency between stats.compressedSize and the stream write count) and relax compressed-size to a ±4-byte window around the reference. The parametrized ZlibCompress / ZlibDecompress suites already run a round-trip check, which catches any real encoder regression.

The Windows vcpkg cache key was only keyed by matrix.vcpkg-version, so changes to: - thirdparty/vcpkg/ports/** (MeshLib's overlay ports) - thirdparty/vcpkg/triplets/** - requirements/windows.txt - thirdparty/install.bat didn't invalidate the cache. A pre-built C:\vcpkg\installed\ tree was restored verbatim and install.bat's "vcpkg install ..." saw every port as "already installed" (total install time: 3.57 ms in the last PR run), so overlay ports never got consulted. Concrete symptom observed on PR #5932 (zlib → zlib-ng-compat overlay): - Linux-vcpkg (which rebuilds vcpkg inside a Docker image every time `prepare-image / linux-vcpkg-build-upload` runs) picked up zlib-ng; compression tests showed -0.3% zip size and -41 to -45% wall time on Release builds. - Windows vcpkg served the cached pre-zlib-ng tree; zip sizes and test times were indistinguishable from master. Fix: include a hashFiles() of the overlay/triplet/requirements/ install-script content in the cache key. First run after merging this takes the full ~20 min vcpkg install; subsequent runs hit the cache again as before.

Resolves conflicts from master's recent work (MRZlib move MRIOExtras→ MRMesh, #5948 adds MRZlibTests.cpp, #5933+#5960 overhaul CompressZip tests, #5957 CUDA cache-key fix, #5722 triplet-keyed vcpkg cache). Conflict resolutions: - .github/workflows/build-test-windows.yml — combined both sides' improvements in the cache key: master-side per-triplet partition (for the x64-windows-meshlib-iterator-debug triplet from #5722) AND branch-side hashFiles(overlay ports / triplets / requirements / install.bat) (from #5934, needed so overlay port changes on this PR bust the cache). Key is now vcpkg-cache-<VERSION>-<TRIPLET>-<HASH>. - source/MRMesh/MRZlib.h — accept master's version (master re-homed the file in #5944; branch had deleted it when it lived briefly in MRIOExtras). - source/MRIOExtras/MRZlib.{h,cpp} — follow master's layout: keep MRIOExtras/MRZlib.h as a forwarding header (#include <MRMesh/MRZlib.h>) and delete MRIOExtras/MRZlib.cpp (the old implementation body, now in MRMesh). - source/MRTest/MRTest.vcxproj — rename ClCompile entry from MRZlib.cpp to MRZlibTests.cpp to match master's #5948 test-file rename. Also drops the duplicate MRZlib.cpp entry. - source/MRTest/MRZlib.cpp — deleted, master renamed to MRZlibTests.cpp in #5948. - source/MRTest/MRZipCompressTests.cpp — accept master's version, which includes the level-0..9 loop (#5960) and the round-trip decompress check (#5958) on top of the branch's earlier simpler version. Branch-side novelty was just the sphere test itself, which is already on master. - source/MRTest/MRZlibTests.cpp — accept master's version, engine-agnostic assertions (tolerance-based compressedSize checks that I relaxed in the zlib-ng PR work). Branch's unique contributions — the actual point of this PR — are preserved: - thirdparty/vcpkg/ports/zlib/{portfile.cmake,vcpkg.json} -- vcpkg overlay port that builds zlib-ng in ZLIB_COMPAT=ON as a drop-in zlib replacement for every port that depends on zlib. - thirdparty/install.bat -- --overlay-ports flag added alongside the existing --overlay-triplets. - thirdparty/vcpkg/downloads/msys2-*.pkg.tar.zst -- pre-staged msys2 packages so vcpkg's pinned 2024.10.21 index doesn't hit stale msys2 mirrors during vcpkg_fixup_pkgconfig().

Post-merge, the pre-commit hook vcxproj-missing-files flagged source/MRMesh/MRMesh.vcxproj: missing ClInclude item: MRZlib.h on the PR branch (run 24830458889, config/prepare-config job). Cause: during the merge-from-master, git's auto-merge took the branch's MRMesh.vcxproj -- the one from when MRZlib briefly lived in MRIOExtras -- which has no MRZlib.h entry. Master's vcxproj, after #5944 moved MRZlib back to MRMesh, lists both MRZlib.h (ClInclude line 419) and MRZlib.cpp (ClCompile line 736). Take master's versions wholesale for the MRMesh/MRTest/MRIOExtras vcxproj + filters files. Those files are hand-maintained and the branch's edits to them were collateral from other intermediate branches that have since been merged to master through unrelated PRs; the zlib-ng-compat vcpkg overlay (the actual point of this PR) doesn't touch these project files.

…zip-zlib-ng-vcpkg

…cpkg

The master-merge earlier on this branch brought in PR #5722's cache-key format (vcpkg-cache-<VERSION>-<TRIPLET>) but dropped the hashFiles() appendix from #5934. On this PR that matters: the last run (24830925083) had a cache hit on the older key and reused a pre- overlay vcpkg installed tree, so "vcpkg install" saw every port already-installed and built zero of this PR's overlay zlib port. Effect: MRMesh.dll and libzip ended up linked against stock zlib, and the CompressSphereToZip numbers on Windows matched master's stock-zlib baseline (1172-1355 ms Release) instead of the zlib-ng speedup we see on Linux-vcpkg legs in the same run (~450 ms Release). Re-add the hashFiles() over thirdparty/vcpkg/{ports,triplets}/, requirements/windows.txt, and thirdparty/install.bat so a change to any of them busts the cache and forces a fresh install. On this PR specifically, that ensures the new thirdparty/vcpkg/ports/zlib overlay actually gets built and replaces stock zlib with zlib-ng- compat in the cached tree. The fix for the unit-test failure (MRMesh.ZlibCompressStats pinned stats.compressedSize against stock-zlib reference byte counts) came in automatically with the master merge -- master's version of source/MRTest/MRZlibTests.cpp uses engine-agnostic assertions.

Replaces the bespoke 67-line portfile.cmake (which re-implemented a zlib-ng compat-mode build via vcpkg_from_github + vcpkg_cmake_configure + vcpkg_cmake_install + vcpkg_fixup_pkgconfig + vcpkg_cmake_config_fixup + file removals) with a 5-line empty-package shim that simply declares `zlib-ng` as its dependency. Pattern borrowed from https://github.com/WebKitForWindows/WebKitRequirements/tree/main/ports/zlib Then sets `ZLIB_COMPAT ON` in each MeshLib triplet (arm64-linux-meshlib, x64-linux-meshlib, x64-windows-meshlib, x64-windows-meshlib-iterator-debug). That's the canonical hook upstream's stock zlib-ng portfile is designed for -- the very first comment in upstream/ports/zlib-ng/portfile.cmake is literally: # Set ZLIB_COMPAT in the triplet file to turn on if(NOT DEFINED ZLIB_COMPAT) set(ZLIB_COMPAT OFF) endif() When `ZLIB_COMPAT=ON`, upstream's zlib-ng port installs ABI-compatible artifacts that shadow stock zlib (libz.so.1 / zlib1.dll, zlib.h, ZLIB::ZLIB target, ZLIB_1.2.0 versioned symbols), so every existing consumer keeps working without code changes. Net effect: thirdparty/vcpkg/ports/zlib/portfile.cmake: 67 -> 5 lines thirdparty/vcpkg/ports/zlib/vcpkg.json: 18 -> 9 lines (now depends on zlib-ng instead of vcpkg-cmake build helpers) 4 triplets: +3-6 lines each ────────────────────────────────────────────── net: 25 insertions, 78 deletions Bumps the overlay's port-version 100 -> 101 to bust vcpkg's per-port ABI cache. The cache-key hashFiles in build-test-windows.yml from a previous commit on this branch is unchanged and continues to pick up edits to ports/triplets/requirements. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…cpkg # Conflicts: # source/MRTest/MRZipCompressTests.cpp

vcpkg 2024.10.21's stock zlib-ng port (zlib-ng 2.1.5#1) has a bug that breaks our `zlib` empty-shim → zlib-ng-compat path on the vs2019 leg: the portfile's vcpkg_cmake_configure block forgets to pass -DZLIB_COMPAT=${ZLIB_COMPAT} (and the matching default-OFF init) to the actual cmake build, so the build always runs in NATIVE mode (producing zlib-ng.pc, libz-ng.dll), regardless of triplet. But the post-install fixup later in the same portfile *does* read ZLIB_COMPAT and goes looking for zlib.pc, which the build never produced: CMake Error at scripts/cmake/vcpkg_replace_string.cmake:12 (file): file failed to open for reading (No such file or directory): .../zlib-ng_x64-windows-meshlib-iterator-debug/lib/pkgconfig/zlib.pc Call Stack: ports/zlib-ng/portfile.cmake:41 (vcpkg_replace_string) vcpkg 2026.03.18 fixes this (zlib-ng 2.3.3, with the missing -DZLIB_COMPAT line and default init), so vs2022 (which uses 2026.03.18) already passes. vs2019 stays pinned to 2024.10.21 to keep its v142 toolchain coverage; pinning vcpkg there cannot be changed without breaking matrix coverage. Solution: overlay our own copy of vcpkg's zlib-ng port that mirrors the 2026.03.18 content (zlib-ng 2.3.3 + the proper ZLIB_COMPAT threading). Vcpkg's --overlay-ports makes our overlay take precedence regardless of which base vcpkg version is in use, so vs2019 and vs2022 now both build zlib-ng 2.3.3 with consistent ZLIB_COMPAT plumbing. A side benefit: vs2019 and vs2022 now produce the same zlib-ng binary version, eliminating the zlib-ng-2.1.5 vs zlib-ng-2.3.3 drift that was previously causing many.zip size differences at deflate levels 1-3 between the two legs. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Fedr added 2 commits April 19, 2026 11:40

Fedr mentioned this pull request Apr 19, 2026

test: add compress-to-zip tests #5933

Merged

Fedr added 3 commits April 19, 2026 15:32

fix

2ceef41

test: log mesh and zip sizes via spdlog::info

96b10ef

Merge branch 'test/zip-compress-sphere' into ci/libzip-zlib-ng-vcpkg

a10e00a

Fedr added the skip-image-rebuild force to skip docker image rebuild label Apr 19, 2026

Fedr mentioned this pull request Apr 19, 2026

ci(windows): bust vcpkg cache on overlay/triplet/requirements changes #5934

Open

Fedr added disable-build-ubuntu-x64 disable-build-ubuntu-arm64 disable-build-macos disable-build-emscripten and removed skip-image-rebuild force to skip docker image rebuild labels Apr 19, 2026

Fedr added 2 commits April 19, 2026 23:58

Merge remote-tracking branch 'origin/ci/windows-vcpkg-cache-key' into…

ab2ad94

… ci/libzip-zlib-ng-vcpkg

Fedr mentioned this pull request Apr 20, 2026

repro: Windows vcpkg fresh install fails on blosc/msys2-pkgconf 404 (do not merge) #5940

Closed

Fedr added 4 commits April 20, 2026 16:48

Fedr added the skip-image-rebuild force to skip docker image rebuild label Apr 20, 2026

Fedr added 3 commits April 20, 2026 20:21

increase timeout for vs2019

f8b3f48

Fedr mentioned this pull request Apr 21, 2026

ci(windows): propagate cmake/ninja build failures out of the Build step #5947

Merged

Fedr added 3 commits April 21, 2026 12:01

Merge remote-tracking branch 'origin/ci/fix-windows-build-step-exit' …

e7e0dcc

…into ci/libzip-zlib-ng-vcpkg

CompressManySmallFilesToZip test only with 2 times more files

26890ed

Merge branch 'test/zip-compress-sphere' into ci/libzip-zlib-ng-vcpkg

0f29fa8

Update vcpkg packages timeout

a63c24e

Fedr marked this pull request as draft April 21, 2026 13:27

.github/workflows/build-test-windows.yml

995abb8

This was referenced Apr 21, 2026

macOS: build libzip from submodule against Homebrew zlib-ng-compat #5950

Closed

MRZip: route compressZip through libdeflate when archive is unencrypted #5952

Closed

Fedr added 2 commits April 22, 2026 10:14

ZipCompressTests: performance testing

d91067a

Merge branch 'master' into test/compress-times

d5b1c37

Fedr mentioned this pull request Apr 22, 2026

MRZlib: route compress and decompress streams through zlib-ng (native mode) #5959

Open

Fedr added 2 commits April 22, 2026 16:28

Merge branch 'master' into test/compress-times

46a3a9a

Merge branch 'master' into test/compress-times

bc071d7

Fedr removed skip-image-rebuild force to skip docker image rebuild disable-build-ubuntu-x64 disable-build-ubuntu-arm64 labels Apr 23, 2026

Fedr added 7 commits April 23, 2026 13:33

reset files

5197bf9

Merge remote-tracking branch 'origin/test/compress-times' into ci/lib…

78da109

…zip-zlib-ng-vcpkg

Merge remote-tracking branch 'origin/master' into ci/libzip-zlib-ng-v…

a40cac8

…cpkg

Merge branch 'master' into ci/libzip-zlib-ng-vcpkg

8941ee7

Fedr added the full-ci run all steps label Apr 26, 2026

Fedr and others added 3 commits April 26, 2026 12:45

Merge remote-tracking branch 'origin/master' into ci/libzip-zlib-ng-v…

84c0f39

…cpkg # Conflicts: # source/MRTest/MRZipCompressTests.cpp

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ci(vcpkg): overlay zlib port with zlib-ng built in compat mode#5932

ci(vcpkg): overlay zlib port with zlib-ng built in compat mode#5932
Fedr wants to merge 34 commits intomasterfrom
ci/libzip-zlib-ng-vcpkg

Fedr commented Apr 19, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

Fedr commented Apr 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What

Scope: vcpkg only

Cache-key fix

Risk notes

Measurement on the next CI run

Rollback

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Fedr commented Apr 19, 2026 •

edited

Loading