macOS: Add vcpkg build support

[oitel]

No description provided.

[Fedr]

PYBIND11_NONLIMITEDAPI_SHIM_INSTALL_DIR doesn't exist in mrbind-pybind11 at the pinned REF f11e5ce81 (which is also the current head of non-limited-api and the submodule commit): the shim's install(TARGETS ...) in source/non_limited_api/CMakeLists.txt hardcodes LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR} / RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}. So this option is silently ignored (only an unused-variable warning), the shim still lands in lib/ (bin/ on Windows) rather than lib/meshlib, and the port-version 1 -> 3 bump just invalidates the binary caches. Looks like the mrbind-pybind11 change adding this option is missing, and REF/SHA512 + the submodule need bumping to it.

[Fedr]

This runs in the consumer's scope for every MeshLib install (not only the macOS vcpkg framework), and PREPEND puts the MeshLib prefix ahead of the consumer's own CMAKE_PREFIX_PATH for all subsequent find_package calls. E.g. with the .deb (prefix /usr/local), a consumer configured with -DCMAKE_PREFIX_PATH=/opt/mydeps that calls find_package(MeshLib) and then find_package(fmt) will now get the /usr/local fmt instead of /opt/mydeps. Checked with a minimal config + consumer: PREPEND picks the package under the MeshLib prefix, APPEND picks the consumer's. Could this be APPEND (or limited to the Apple/vcpkg package)?

[Grantim]

ia there a way to unify build_source + build_vcpkg_source and build_thirdparty + build_vcpkg_thirdparty? to have two scripts instead of four? (does this unification make sense at all?)

[Grantim]

should this script support windows too?

[oitel]

The shell scripts aren't called on Windows. Also, on Windows uname -s might return a wide variety of values.

[MaxRayskiy]

Tested locally on Apple Silicon: developer build and consumer .pkg

Environment

Machine	Apple M4, 24 GB, macOS 15.7.1
Compiler	Apple clang 17.0.0 (clang-1700.0.13.5) from Command Line Tools, SDK 15.5, no Xcode.app
CMake / Ninja	4.4.0 / Homebrew ninja
vcpkg	tag 2026.07.29, tool 2026-07-27, triplet arm64-osx-meshlib, manifest mode
Python	3.12.13 from vcpkg, picked up automatically by FindPython
Homebrew	arm64 at /opt/homebrew, plus an Intel Homebrew at /usr/local
Not built	MRBind Python bindings, generated C bindings

What I ran

1. scripts/build_vcpkg_thirdparty.sh with VCPKG_MAX_CONCURRENCY=5
2. MESHLIB_BUILD_RELEASE=ON scripts/build_vcpkg_source.sh: 699 targets in 3 min. See the note below, it did not pass as-is.
3. MRTest: 420 passed. MeshViewer -tryHidden -noEventLoop -unloadPluginsAtEnd exits clean; DYLD_PRINT_LIBRARIES shows all 82 third-party libraries coming from vcpkg_installed, none from Homebrew.
4. scripts/distribution_vcpkg_macos.sh v0.0.0.0: 90 MiB installer. The current Homebrew-based arm64 package is 73 MiB.
5. installer -pkg MeshLib_.pkg -target CurrentUserHomeDirectory, then meshconv and MeshViewer from the framework: both load only framework and system libraries. All 318 shipped binaries verify as ad hoc signed. Minimum OS is 12.0 for the vcpkg libraries and 12.7 for ours.
6. examples/cpp-examples with a plain find_package(MeshLib CONFIG REQUIRED): all 30 build and run. Every *_DIR resolves inside the framework even though Homebrew's boost, tbb, fmt, spdlog and jsoncpp are installed here. It also passes with -DCMAKE_IGNORE_PREFIX_PATH="/opt/homebrew;/usr/local", so the package really needs no brew step. C examples are not applicable to my build.
7. MESHLIB_USE_VCPKG=ON VCPKG_MANIFEST_MODE=ON scripts/build_source.sh on the same build directory: no rebuild at all, so the two source scripts are equivalent. That supports Grantim's question about collapsing them.

Warning

Step 2 as committed failed for me linking libMRVoxels with undefined openvdb::v13_0abi13 symbols.
Apple clang searches /usr/local/include before every -isystem path when no -isysroot is given, CMake 4 leaves CMAKE_OSX_SYSROOT empty, and my Intel Homebrew has OpenVDB 13 under /usr/local. This fixed it:

MR_CMAKE_OPTIONS="-D CMAKE_OSX_SYSROOT=$(xcrun --show-sdk-path)" scripts/build_vcpkg_source.sh

Anyone with an Intel Homebrew or anything else in /usr/local/include will hit this. Suggest setting the sysroot in CMakeLists.txt next to the deployment target, and VCPKG_OSX_SYSROOT in the two osx triplets so the ports get it too.

Package content

distribution_vcpkg_macos.sh copies the entire vcpkg tree and only removes pkgconfig, tools and __pycache__. What ends up in the framework:

Location	Finding
include/, 171 MB	16,173 third-party headers, including 5,622 OpenCASCADE, 469 Xerces, 142 OpenSSL and 214 Python headers that are private dependencies
share/, 31 MB	523 CMake config files we need, plus 141 vcpkg_abi_info.txt, 141 vcpkg.spdx.json, 134 vcpkg-spdx-resources.json and 104 usage files that are vcpkg bookkeeping
src/, etc/	gtest sources, and an OpenSSL config skeleton that libcrypto never reads (OPENSSLDIR is /etc/ssl)
AppleDouble sidecars	a ._name entry per file, because cp -a keeps the com.apple.provenance xattr and pkgbuild encodes it
Build paths	63 modules in lib/python3.12/lib-dynload carry an LC_RPATH pointing at the builder's vcpkg_installed path; vcpkg's rpath fixup skips this directory. No functional impact (imports still resolve through libpython's @loader_path rpath), but it is a foreign absolute path in a shipped product. 70 of 303 vcpkg dylibs also embed the builder's buildtrees paths via assert macros.

Summary

• Step 2 link failure (headers from /usr/local shadowing vcpkg's, not a dependency conflict): I will fix it on my side in #6448
• Package contents: mb create a separate issue to determine explicitly what do we ship in our macos pkgs?