MSVC: compile sources in parallel (/MP) under Visual Studio generators

[revarbat]

On Windows, cmake --build -j becomes MSBuild's /m. That runs projects in parallel, but MSVC compiles each project's files one at a time unless /MP is set. Nearly all of the evaluator is one large library, so its Windows build is close to serial:

• CI's Build step takes ~665 s on Windows, against ~250 s on Linux and, since CI: bound the build's job count on the Unix runners #221, ~215 s on macOS.
• The Windows wheels take 19 min, the slowest wheel job.

This adds /MP for MSVC, under Visual Studio generators only. Under Ninja each compiler call is already a single file, so it would do nothing there. It's set in the top-level if(MSVC) block before add_subdirectory/FetchContent, so the vendored parser and the dependencies (Manifold, Clipper2, …) get it too.

Result: about 26–28% faster on Windows. Measured as follows:

Windows	Before	With /MP
CI Build step	689, 677, 665, 495 s (median ≈ 671)	511, 499, 353 s (median 499)
Wheel job	16.2–20.6 min over 7 runs (median 20.2)	14.4, 14.5 min

Both /MP wheel runs came in under the fastest earlier Windows wheel build. The Windows wheels use the Visual Studio generator too, so they get /MP (confirmed in the log). The compiler command lines show /MP with several source files per call, dependencies included. macOS and Linux are unaffected.

The third CI sample's Build step never got a completion time from GitHub's API, so its 353 s comes from the job log's timestamps. That method gives exactly 511 s for attempt 1, matching the API.

It's a modest gain. Windows is still about 2× the other platforms, so something besides file-level parallelism dominates there; that's a separate investigation.

🤖 Generated with Claude Code