Windows wheels: port FronTier to compile under MSVC (or build via clang-cl/MinGW)

[jcschaff]

Background

Python wheels now build cleanly for Linux (x86_64 + arm64) and macOS (x86_64 + arm64) via the Wheels GitHub Actions workflow (added in #1). Windows is intentionally excluded from the matrix.

Windows was taken all the way through dependency setup successfully — using conda-forge for prebuilt HDF5 + Boost, with find_package for HDF5/Boost/Python3/pybind11 all resolving — but the build then fails when compiling the bundled FronTier library under MSVC. This is a source-level incompatibility, not a CI/dependency-management problem.

(For reference: vcell-fvsolver builds on Windows because it does not depend on FronTier. vcell-mbsolver hard-links frontier.)

The blocker

FronTier is Unix/GCC code. On Linux/macOS it is compiled with -fpermissive (a GCC/Clang-only flag with no MSVC equivalent). Under MSVC the compile fails with, among others:

FronTierLib/util/cdecs.h(189): error C2059: syntax error: 'constant'
FronTierLib/util/cdecs.h(195): error C2371: 'boolean': redefinition; different basic types
FronTierLib/util/uprotos.h(67): error C2143: syntax error: missing ';' before '{'
FronTierLib/intfc/int.h(72):  error C2332: 'struct': missing tag name
FronTierLib/intfc/int.h(92):  error C2371: 'POINT': redefinition; different basic types
FronTierLib/intfc/int.h(145,200,279,353,400): error C2226: unexpected type '_CURVE/_NODE/_SURFACE/...::<unnamed-tag>'

Root causes:

• POINT / boolean collide with the Windows SDK typedefs (pulled in transitively via windows.h / rpcndr.h).
• GCC anonymous-struct/<unnamed-tag> extensions that MSVC rejects.
• FronTier's windows_math_func.h already shims some math symbols (isnan, isgreater, erf, erfc, rint) but the core headers (cdecs.h, int.h, uprotos.h) are not MSVC-clean.

Options to investigate

1. Build FronTier with clang-cl (clang frontend, MSVC ABI) instead of cl. More GCC-compatible (may handle anonymous tags), but the POINT/boolean symbol clashes are real and may still need source patches. Lowest-effort thing to try first.
2. Build FronTier with MinGW/gcc on Windows — supports -fpermissive and the GCC-isms, but the resulting Python extension must be ABI-compatible with the (MSVC-built) CPython; mixing toolchains is problematic.
3. Port FronTier headers to MSVC — e.g. NOMINMAX + avoid windows.h, rename/guard POINT/boolean, replace anonymous tags with named ones. Most thorough but a substantial, open-ended effort on vendored third-party C code.

Acceptance criteria

• FronTier (and the rest of MovingBoundaryLib) compiles on Windows.
• pyvcell_mbsolver extension links and imports on Windows.
• windows-* runner re-added to the matrix in .github/workflows/wheels.yml (HDF5/Boost via conda-forge is already worked out and can be restored from the Add Python wheel packaging and CI wheel builds #1 history), with delvewheel vendoring the HDF5 DLLs.
• README / CLAUDE.md updated to remove the "Windows not supported" note.

Pointers

• Workflow: .github/workflows/wheels.yml (matrix comment documents why Windows is absent).
• The conda-forge Windows dep setup that already worked is in PR Add Python wheel packaging and CI wheel builds #1's history (commits prior to the "Drop Windows wheels" commit) and can be restored.
• FronTier sources: FronTierLib/ (util/cdecs.h, util/uprotos.h, intfc/int.h, windows_math_func.{h,c}).

🤖 Generated with Claude Code