From b75422d605094205f5db7d5d676ded7039388d03 Mon Sep 17 00:00:00 2001 From: lEWFkRAD <186512915+lEWFkRAD@users.noreply.github.com> Date: Thu, 16 Jul 2026 14:35:30 -0400 Subject: [PATCH] =?UTF-8?q?ci:=20build=20the=20Windows=20CUDA=20path=20(nv?= =?UTF-8?q?cc=20+=20MSVC=20host)=20=E2=80=94=20the=20one=20toolchain=20no?= =?UTF-8?q?=20job=20covers?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 ` — 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 --- .github/workflows/ci.yml | 72 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 72 insertions(+) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index e18f1b3..72b7149 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -41,6 +41,78 @@ jobs: -Xcompiler=-Wall,-Wextra echo "CUDA syntax check passed" + windows-cuda-build: + # The Windows CUDA path has no coverage anywhere: `engine-cuda-syntax` above + # compiles with nvcc's *GCC* host on Linux, and check.yml's windows job is + # MinGW/UCRT64 CPU-only by design (#140). But nvcc on Windows requires MSVC + # as its host compiler — it does not accept MinGW — so `make cuda-dll` runs a + # toolchain nothing else in CI touches. That gap is not theoretical: every + # bug in #158 was a *build* failure on this path (MSVC rejects the GCC-style + # -Xcompiler=-Wall,-Wextra with "D8021 invalid numeric argument '/Wextra'", + # unresolvable CUDA_HOME/NVCC defaults, POSIX setenv in the kernel test), and + # #314 was CUDA_HOME with spaces — the layout the CUDA installer ships by + # default. Both classes are compile-time and need no GPU to catch. + # + # Build-only ON PURPOSE: GitHub's hosted runners have no NVIDIA device, so + # this job proves the Windows+MSVC CUDA build stays buildable, NOT that the + # kernels or the DLL loader behave on real silicon. That still needs hardware + # (see #157). Claiming otherwise would be the false confidence the + # engine-cuda-syntax comment above already warns about. + name: CUDA build (Windows, MSVC host) + # windows-2022, NOT windows-latest: the latest image now ships Visual Studio + # 18 (MSVC 14.5x), and CUDA's crt/host_config.h hard-errors on any host newer + # than VS 2022 ("Only the versions between 2017 and 2022 (inclusive) are + # supported"). That is a real constraint for every CUDA user on Windows, not + # a CI quirk — pinning tracks what the toolkit actually supports. Revisit when + # a CUDA release accepts VS 18; -allow-unsupported-compiler would only mask it. + runs-on: windows-2022 + steps: + - uses: actions/checkout@v4 + - name: MSVC environment (puts cl.exe on PATH for nvcc -ccbin) + uses: ilammy/msvc-dev-cmd@v1 + - name: Install CUDA toolkit (compiler only) + uses: Jimver/cuda-toolkit@v0.2.19 + with: + # Same pin as engine-cuda-syntax: v0.2.19's version table stops at + # 12.6.2. This installs to the default "C:\Program Files\NVIDIA GPU + # Computing Toolkit\..." path, so CUDA_HOME is space-bearing here — + # which is exactly the #314 regression this job would have caught. + cuda: '12.6.2' + method: network + # cudart as well as nvcc: unlike the Linux job (which only needs to + # *compile* backend_cuda.cu), cuda-dll links it, and on Windows the + # runtime headers/import lib ship as a separate installer component — + # with '["nvcc"]' alone this fails at `#include `. + sub-packages: '["nvcc", "cudart"]' + - uses: msys2/setup-msys2@v2 + with: + msystem: UCRT64 + update: false + # inherit: cl.exe (msvc-dev-cmd) and nvcc (cuda-toolkit) are added to + # the *Windows* PATH by the steps above; without inheriting it the + # recipe's `command -v` guards fail inside the MSYS2 shell. + path-type: inherit + install: >- + make + mingw-w64-ucrt-x86_64-gcc + - name: make cuda-dll (nvcc + MSVC host) + shell: msys2 {0} + run: | + cd c + # CUDA_ARCH is pinned: the default is `native`, which asks the driver + # what card is present — there is none here, so it must be explicit. + # sm_80 matches engine-cuda-syntax and is supported by the 12.6 pin. + make cuda-dll CUDA_ARCH=sm_80 + test -f coli_cuda.dll || { echo "cuda-dll reported success but produced no DLL" >&2; exit 1; } + echo "coli_cuda.dll built (MSVC host)" + - name: make glm CUDA_DLL=1 (host links backend_loader, not cudart) + shell: msys2 {0} + run: | + cd c + make glm CUDA_DLL=1 + test -f glm.exe || { echo "glm CUDA_DLL=1 reported success but produced no exe" >&2; exit 1; } + echo "glm.exe built against the DLL loader" + web: name: Web UI runs-on: ubuntu-latest