[NiJingzhe]

Building from source on Windows without MSVC, with MinGW-w64 gcc (gcc 15.2.0, CMake 4.5, ninja 1.13, Python 3.10 from uv), two things break; this PR fixes both.

1. _USE_MATH_DEFINES for MinGW (ScadCompile.cmake)

The scad targets compile with -std=c++20 (strict ANSI, CMAKE_CXX_EXTENSIONS OFF). OCCT's geometry headers (gp_Dir.hxx, gp_Vec.hxx, gp_Dir2d.hxx, gp_Vec2d.hxx, …) use M_PI/M_PI_2, and MinGW's math.h exposes those under strict ANSI only when _USE_MATH_DEFINES is defined. MSVC already gets the define in the MSVC branch of scad_apply_compile_options, which is why MSVC and Linux/macOS gcc builds never see this — MinGW was the one case left out, so every TU that includes an OCCT geometry header fails with 'M_PI' was not declared in this scope. The fix adds the same define in a MINGW branch.

2. Ninja in build_occt.py when g++ is the compiler

On Windows the script only selects Ninja when cl is on the PATH; without MSVC it leaves the generator to CMake, which falls back to NMake and dies with 'nmake' '-?' failed with: no such file or directory. With a MinGW g++ on the PATH, CMake's Ninja generator detects gcc/g++ on its own, so the condition now also accepts g++. Behaviour with cl present (the release workflow) is unchanged.

Not changed here (environment note)

scikit-build-core 1.1.2 under uv sync build isolation did not pick Ninja by itself on this setup, so a MinGW source build currently still needs CMAKE_GENERATOR=Ninja exported. The local recipe that now works end to end:

set CMAKE_GENERATOR=Ninja
set CMAKE_ARGS=-DSCAD_OCCT_PREFIX=<occt prefix>
python src/cpp/tools/build_occt.py --prefix <occt prefix>
uv sync --group dev

Verification

Full uv sync --group dev editable build with gcc 15.2.0 (MinGW-w64) against a static OCCT V7_9_3 built by tools/build_occt.py; smoke test:

union_rsolid(make_box_rsolid(10, 20, 30), make_cylinder_rsolid(5, 40)).get_volume()
# 6785.398163397445 — box (6000) + cylinder minus the exact overlap through the box height

MSVC, Linux and macOS are untouched: the compile definition is MINGW-scoped, and the script's generator choice is identical whenever cl is present.

[NiJingzhe]

Superseded by #81 (same two commits, flowing through dev per the usual release path).