engine-cuda-syntax compiles backend_cuda.cu with nvcc's GCC host on Linux, and
check.yml's windows job is MinGW/UCRT64 CPU-only by design (#140). Neither
exercises nvcc's MSVC host — the only host compiler nvcc accepts on Windows — so
`make cuda-dll` and `make glm CUDA_DLL=1` are currently built by nothing.
The gap has already cost real bugs, all compile-time, all catchable without a GPU:
- #158: MSVC rejects the GCC-style -Xcompiler=-Wall,-Wextra ("D8021 invalid
numeric argument '/Wextra'"), CUDA_HOME/NVCC defaults were unresolvable, and
the kernel test used POSIX setenv. `make cuda-dll` was unbuildable as shipped.
- #314: CUDA_HOME containing spaces — the CUDA installer's default layout. This
job installs to exactly that path, so it reproduces the condition by default.
Two Windows-specific facts the job encodes, both verified by making it fail first:
- sub-packages needs "cudart", not just "nvcc": cuda-dll *links* the runtime, and
on Windows the headers/import lib are a separate installer component. With
'["nvcc"]' alone it dies at `#include <cuda_runtime.h>` — the Linux syntax job
never notices because it only compiles.
- runs-on is pinned to windows-2022: windows-latest now ships Visual Studio 18
(MSVC 14.5x) and CUDA's crt/host_config.h hard-errors on any host newer than
VS 2022. That is a real constraint on every Windows CUDA user today, so the pin
tracks what the toolkit supports rather than papering over it with
-allow-unsupported-compiler.
Build-only on purpose: hosted runners have no NVIDIA device, so this proves the
Windows+MSVC CUDA build stays buildable, not that the kernels or the DLL loader
behave on real silicon — that still needs hardware (#157). A check that overclaims
buys the false confidence the engine-cuda-syntax comment already warns about.
Verified green on a fork before proposing:
https://github.com/lEWFkRAD/colibri/actions/runs/29524302993
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
lEWFkRAD
b75422d605