macOS: build libzip from submodule against Homebrew zlib-ng-compat#5950
Closed
macOS: build libzip from submodule against Homebrew zlib-ng-compat#5950
Conversation
Previously macOS picked up libzip from Homebrew, which is linked against
Homebrew's stock zlib. To get zlib-ng's deflate into the compressZip hot
path on macOS, we now build the thirdparty/libzip submodule (already
pinned to v1.11.4) on macOS as well, and swap the brew 'zlib' requirement
for the 'zlib-ng-compat' drop-in replacement. The replacement formula is
keg-only, so scripts/build_{thirdparty,source}.sh export ZLIB_ROOT
pointing at its keg prefix; both libzip's internal find_package(ZLIB) and
MRMesh's top-level find_package(ZLIB) then resolve to zlib-ng.
No changes on other platforms.
Fedr
added
disable-build-windows
disable-build-ubuntu-x64
disable-build-ubuntu-arm64
disable-build-linux-vcpkg
disable-build-emscripten
skip-image-rebuild
6 tasks
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.
After dropping libzip from Homebrew requirements in favour of the thirdparty/libzip submodule build, the main MeshLib cmake invocation (a separate process from the thirdparty build) could no longer locate libzipConfig.cmake: it lives under MESHLIB_THIRDPARTY_ROOT_DIR/lib/cmake/ libzip/, which is not on CMake's default find_package search path on a macOS runner without a stale Homebrew libzip in /opt/homebrew. The x64 Release legs happened to have such a stale copy; arm64 Debug did not, exposing the bug. Fix: pass HINTS pointing at the thirdparty install location. Same pattern already used for libdeflate in #5952; harmless on vcpkg-based configurations because their toolchain file supplies CMAKE_PREFIX_PATH ahead of the hint.
4 tasks
Contributor
Author
|
Closing in favour of #5959 (zlib-ng native, cross-platform). Comparison summary of
Release legs are within noise. arm64 Debug actually favours #5959 by ~30 % (4116 ms vs 2886 ms). On top of that, #5950 meaningfully increases build time on every macOS run because it stops using Homebrew's pre-built libzip bottle and instead builds Combined with the cross-platform coverage (all five platform families vs macOS-only), #5959 is strictly the better path. Closing this PR and its branch. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Routes macOS's
compressZip/MRZlibhot path through zlib-ng (compat mode), without adding any new submodule.thirdparty/libzipsubmodule (pinned tov1.11.4) on macOS as well as Emscripten. Other platforms continue to pick up libzip from apt / brew / vcpkg.zlibrequirement forzlib-ng-compat, which installs a drop-inlibz.dylib/zlib.h/zlib.pc. The formula iskeg_only :shadowed_by_macos, soscripts/build_thirdparty.shandscripts/build_source.shnow exportZLIB_ROOT=\$(brew --prefix zlib-ng-compat)on darwin.libzip's internalfind_package(ZLIB)and MRMesh's top-levelfind_package(ZLIB)both resolve to zlib-ng-compat on macOS. The Emscripten path is untouched (still uses-s USE_ZLIB=1).libzipis dropped fromrequirements/macos.txt(we build our own), andzlibis replaced byzlib-ng-compat(drop-in).Benchmark precedent: on Rocky (#5932 + #5933 measurement), the same substitution produced ~60%+ speedup on `MRMesh.CompressSphereToZip` / `MRMesh.CompressManySmallFilesToZip`.
Why scoped to macOS only: apt, Rocky-vcpkg and Windows-vcpkg each need their own mechanism (#5932 is the vcpkg-overlay side; apt would need a submodule zlib-ng). This PR lands cleanly without extra submodules or overlay ports because brew already packages `zlib-ng-compat`.
Test plan
Related
🤖 Generated with Claude Code