Make the C++/CUDA Makefiles portable (Windows build support)

[balbasty]

Problem

The C++ build system assumes a Unix/clang toolchain, so it does not build on Windows. The new CI test matrices (fastfields-numpy / -cupy / -torch / -bind-py / fastfields) run a windows-latest leg that builds fastfields-dlpack from source, and that leg is currently expected to be red until this is addressed. The windows-latest steps carry a comment saying as much.

What's not portable

The Makefiles in fastfields-cpu-lib, fastfields-cuda-lib, and fastfields-lib (and, transitively, the build fastfields-bind-py/setup.py invokes) rely on:

• clang-only flags — -ferror-limit, -ftemplate-backtrace-limit (rejected by MSVC/cl), and clang/gcc-style -fPIC, -fvisibility=hidden, -Wl,... linker syntax.
• Unix artifacts — hard-coded .so suffix and $ORIGIN rpath (Windows has no rpath; it needs .dll + delvewheel/PATH-based loading).
• Submodule symlinks — the dev tree wires layers with symlinks (lib/cpu -> cpu-lib, cpu-lib/impl -> cpu-impl, cpu-impl/kernels -> kernels); Windows checkouts don't get symlinks by default.
• GNU make + POSIX shell assumptions in the recipes.

Scope / possible approach

• Support MSVC (cl) and/or clang-cl on Windows; branch the compiler/linker flags per toolchain (the existing PLATFORM detection in the Makefiles is the natural place).
• Emit .dll/.lib on Windows and drop the $ORIGIN rpath there; let delvewheel vendor the DLLs into the wheel.
• Make the layer wiring not depend on symlinks (real submodule checkouts, or an include-path variable).
• Once green, the windows-latest legs in the Python test.yaml matrices can be relied on.

CPU is the source of truth; the CUDA (nvcc) Windows build can follow.

Cross-cutting across fastfields-cpu-lib, fastfields-cuda-lib, fastfields-lib, fastfields-bind-py.

Workstream: claude-jitfields-to-fastfields

[balbasty]

Substantially addressed on claude/jitfields-fastfields-migration-v5r416 (across fastfields-cpu-lib, fastfields-lib, fastfields-bind-py, and the Python wrapper repos). The approach is clang everywhere (not MSVC cl), which the CI already assumes (choco install llvm), so the clang-only flags (-ferror-limit, -ftemplate-backtrace-limit, -fvisibility=hidden) are kept and only the truly non-portable bits are branched.

Done

• Makefiles (fastfields-cpu-lib, fastfields-lib): native Windows is detected via OS=Windows_NT and unified with the MINGW*/MSYS shells into one FF_WINDOWS block. There, SOSUF=dll and the POSIX-only -fPIC, -Wl,-soname, and $ORIGIN rpath are cleared. Link/object rules reference these through PICFLAG/SONAME_PREFIX/RPATH variables instead of hard-coding them, so Linux/macOS/CUDA builds are unchanged (verified: a full-matrix make all still links libfastfields-cpu.so on Linux; Windows dry-runs drop -fPIC/-soname and emit .dll).
• fastfields-bind-py/setup.py + dlpack/__init__.py: the hard-coded .so suffix (which also broke macOS, where the Makefile emits .dylib) is now derived from sys.platform — .so/.dylib/.dll with $ORIGIN/@loader_path/none for the rpath. On Windows the extension links the DLL by path (no import lib is produced) and drops -fPIC, and the loader uses os.add_dll_directory + plain CDLL (no RTLD_GLOBAL).
• CI: the windows-latest legs' "red by design" comment is updated; shell: bash was already in place.

Symlinks: not an issue for CI — actions/checkout … submodules: recursive fetches the real submodules (the symlink wiring is dev-tree only).

Still open (why this stays open):

• The Windows leg has not been run on a real runner, so the import-library / DLL-search specifics can only be confirmed live. This targets a MinGW-w64 clang toolchain (the one that makes the Unix Makefiles + git-bash recipes work); an MSVC-target clang would need different link handling.
• CUDA on Windows (nvcc) is untouched — CPU is the source of truth, and there is no GPU/Windows-CUDA in CI.
• delvewheel-style DLL vendoring for wheels is not wired up (only matters once a Windows wheel is actually built).

Leaving open until a live Windows CI run confirms the leg is green.

---

Generated by Claude Code

[balbasty]

Closing: the C++ Makefile + bind-py setup.py Windows portability is delivered and merged (cpu-lib #3, lib #7, bind-py #2), and cpu-lib/lib/bind-py CI is green. Remaining Windows-specific items are tracked separately: the bind-py from-source macOS/Windows build (fastfields/fastfields-dlpack#6) and the cuda-lib nvcc build (fastfields/fastfields-cuda-lib#8). Submodule fetch is no longer an issue now that the repos are public.

---

Generated by Claude Code