Skip to content

Windows wheels, NuGet, Rust and Java natives from the clang-cl CMake build - #7202

Merged
Fedr merged 5 commits into
masterfrom
clang-cl-release-binaries
Oct 21, 2026
Merged

Windows wheels, NuGet, Rust and Java natives from the clang-cl CMake build#7202
Fedr merged 5 commits into
masterfrom
clang-cl-release-binaries

Conversation

@Fedr

@Fedr Fedr commented Oct 20, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

The Windows binaries that reach users through the package managers now come from the clang-cl CMake build that #7193 added, instead of MSBuild + VS2026:

  1. Python wheels. The Windows job of pip-build.yml builds MeshLib the way the clang-cl jobs of build-test-windows.yml do: CMake + Ninja with the image's clang-cl and lld-link, then the same z-applocal deployment and copy into source\<arch>\Release that the bindings and the wheel script expect. x64 runs on the 14.4 (VS2022) toolset with the x64-windows-vs2022-meshlib triplet and CUDA 12.0.1 (CUDA 12 needs that toolset, see Windows: build with clang-cl through CMake #7193), arm64 on VS2026 with CUDA 13.4.1. MSBuild and its setup step leave the job; MSYS2 and mrbind now install before the build, as in the other workflow.
  2. NuGet. The payload steps ("Create and fix fake Wheel for NuGet", the DotNetPatchArchiveWindows-* and DotNetDllXml uploads) move from the msvc-2026 MSBuild Release jobs to the clang-cl Release jobs, so BUILD_C_SHARP moves to the clang-cl jobs: they generate the C# bindings, build the C# examples and run the C# unit tests against the clang-cl DLLs; the MSBuild VS2026 jobs no longer do, and keep producing the C++ developer distribution (MeshLibDistVS26*.zip), which is unchanged.
  3. Rust and Java. pack_crate.sh cuts the per-platform natives (meshlib_<version>_rust_native_windows-*.zip, which the crate's build.rs downloads and pack_maven.sh turns into the natives jars) out of the NuGet package's runtimes/win-*/native, so they follow the NuGet payload with no further change.

Labels: test-pip-build runs the wheel jobs, upload-binaries runs the NuGet assembly (create-nuget-package with the pr-test namespace).

Artifact sizes against master

The pr-test release of this PR's run (v1.0.0.6322, run 39410264571) against master's v3.1.4.589:

Asset master (MSBuild VS2026) this PR (clang-cl) change
MeshLib nupkg 170.2 MB 172.1 MB +1.1%
natives windows-x86_64 zip (Rust crate, Maven jar) 22.9 MB 24.0 MB +5.1%
natives windows-aarch64 zip 22.6 MB 23.3 MB +3.4%
meshlib_core win_amd64 wheel 39.0 MB 40.0 MB +2.6%
meshlib_core win_arm64 wheel 36.6 MB 37.7 MB +2.9%
meshlib win_amd64 wheel 18.8 MB 19.0 MB +1.4%
meshlib win_arm64 wheel 18.7 MB 18.8 MB +0.7%

The master wheels are the nightly run's of the same day (3.1.4.582, run 39357805778, MSBuild). Their DLLs change exactly as the nupkg's below; the largest part of a wheel, mrmeshpy.pyd (56 MB uncompressed), is built by the MSYS2 clang in both and stays the same, which is why the wheels grow by less than the natives.

Per binary, uncompressed KB, from the nupkg's runtimes/win-*/native:

Binary x64 master x64 PR arm64 master arm64 PR
MRMesh.dll 5718 6887 +20% 5575 5853 +5%
MRVoxels.dll 4001 5283 +32% 4038 5028 +25%
MRIOExtras.dll 1205 1654 +37% 1214 1320 +9%
MRSymbolMesh.dll 113 112 -1% 114 110 -4%
MRCuda.dll 1986 1568 -21% 1286 1042 -19%
MeshLibC2.dll 8702 9375 +8% 9175 8438 -8%
MeshLibC2Cuda.dll 96 90 -6% 96 84 -12%
third-party DLLs together 44390 45156 +2% 47546 48178 +1%
total 66211 70115 +5.9% 69170 70167 +1.4%

The third-party difference is two DLLs the MSBuild packages never had, gdcmMEXD.dll and socketxx.dll (about 0.6 MB per architecture): CMake put gdcmMEXD.lib before gdcmDSED.lib on MRVoxels' link line and gdcm re-exports the DSED symbols from every module, so MRVoxels imported the DICOM network module and its socket++ dependency. a08afd0 drops gdcmMEXD from MRVoxels' link list; the sizes above predate it.

LTO does not help

Local clang-cl builds of this configuration with link-time optimization, same flags otherwise (Ryzen 9 3900X, 24 threads):

plain ThinLTO (CMAKE_INTERPROCEDURAL_OPTIMIZATION=ON) full LTO (-flto)
MRMesh.dll 6923 KB 7284 KB (+5%) 7466 KB (+8%)
MRViewer.dll 5598 KB 5929 KB (+6%) 5906 KB (+6%)
MRVoxels.dll 5294 KB 5033 KB (-5%) 4995 KB (-6%)
imgui.dll 1257 KB 1749 KB (+39%) 1760 KB (+40%)
10 main binaries 30.1 MB 31.2 MB (+4%) 31.4 MB (+4%)
clean build, all targets 155 s 169 s 314 s
decimation, 5 cases, vs plain 1.00 0.98-1.02 0.96-0.99
booleans, 6 cases, vs plain 1.00 0.98-1.01 0.98-0.99

LTO inlines more across translation units and the binaries grow; the speed-up stays within 1-4%, so it stays off.

🤖 Generated with Claude Code

@Fedr @claude
Windows wheels, NuGet payload, Rust and Java natives from the clang-c…
bfefb8f 
…l CMake build

The wheel job of pip-build.yml builds MeshLib the way the clang-cl jobs of
build-test-windows.yml do: CMake + Ninja with the image's clang-cl and
lld-link, x64 on the 14.4 toolset with the vs2022 vcpkg triplet and CUDA
12.0.1, arm64 on VS2026 with CUDA 13.4.1; MSBuild leaves that job.

The NuGet payload (DotNetPatchArchiveWindows-*, DotNetDllXml) now comes
from the clang-cl jobs, so the C# bindings are generated and tested there
too; the MSBuild VS2026 jobs keep generating and testing them, and keep
shipping the C++ developer distribution. The Rust crate natives and the
Maven natives jars are cut from the NuGet package, so they follow.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@Fedr Fedr added test-pip-build Build Python wheels (and discard them) upload-binaries Upload built installers and packages to the Releases page labels Oct 20, 2026
Fedr and others added 4 commits October 20, 2026 13:05
@Fedr @claude
pip-build: the z-applocal loop uses the project's vcpkg, not the VS-b…
b227a62 
…undled one VsDevCmd puts in VCPKG_ROOT

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@Fedr @claude
C# tests: accept the results of builds with FMA instructions
745ae54 
clang-cl keeps /fp:precise as -ffp-contract=on, and on arm64 FMA is baseline,
so three tests saw slightly different exact results than the cl builds: the
multiway ICP pair count, the split of the precise edge-triangle intersections
and the edge chosen to represent a projected point. The tests now accept both
result sets, as MRMeshBooleanTests.cpp already does, and check the projected
point through mesh.triPoint instead of its edge id.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@Fedr @claude
MRVoxels: do not link gdcmMEXD
a08afd0 
gdcm builds every module with the same GDCM_EXPORT macro, so gdcmMEXD.dll re-exports
153 gdcmDSED symbols (DataSet, DataElement, Tag...). CMake orders the link line with
gdcmMEXD.lib before gdcmDSED.lib, so MRVoxels resolved them from gdcmMEXD and the
CMake Windows packages shipped gdcmMEXD.dll plus its socket++ dependency, two DLLs the
MSBuild packages never had (vcpkg autolink lists the libs alphabetically, DSED first).
MRVoxels uses only the MSFF and DICT modules; MEXD is the DICOM network module.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@Fedr @claude
CI: the C# bindings are built and tested on the clang-cl jobs only
b5b28cc 
Nothing shipped uses the MSBuild-built C bindings any more, so the MSBuild
VS2026 jobs stop generating and testing the C# bindings.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@Fedr
Fedr merged commit d168f24 into master Oct 21, 2026
128 checks passed
@Fedr
Fedr deleted the clang-cl-release-binaries branch October 21, 2026 08:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@Grantim Grantim Grantim approved these changes
@adalisk-emikhaylov adalisk-emikhaylov adalisk-emikhaylov approved these changes

Assignees

No one assigned

Labels

test-pip-build Build Python wheels (and discard them) upload-binaries Upload built installers and packages to the Releases page

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@Fedr @Grantim @adalisk-emikhaylov