feat(compat.opencl): the loader builds on Windows, and the test stops skipping there (#379)

* feat(compat.opencl): the loader builds on Windows, and the test stops skipping there

The package had linux and macosx entries and no windows one, so a Windows
consumer had no OpenCL loader to link and `tests/examples/opencl` compiled to a
printed skip. The gap was stated in the recipe and tracked nowhere.

Upstream has supported Windows all along: `loader/windows/` enumerates drivers
from `HKLM\SOFTWARE\Khronos\OpenCL\Vendors`, from the display adapters through
DXGK, and from installed app packages, and loads each with LoadLibrary. The
section here is upstream's WIN32 source list with upstream's two link
libraries, `cfgmgr32` and `runtimeobject`.

NO RUNTIME ADAPTER, AND THE ASYMMETRY IS THE POINT. `compat.opencl-runtime`
exists to undo mcpp's PRIVATE loader on Linux, where a bare-soname dlopen from
inside an mcpp binary does not search the host's library path. A Windows
artifact runs under the system loader and every registry entry names a DLL by
absolute path, so there is nothing to undo -- this platform gets a loader with
no adapter beside it.

STATIC, as on macOS. A program that wants THE system loader links the vendor's
`OpenCL.lib` against `C:\Windows\System32\OpenCL.dll`; a package shipping a
second `OpenCL.dll` would compete with that rather than converge on it. Static
also keeps `loader/windows/OpenCL.def` out of the build, which only a DLL
needs.

The member test now declares the dependency unconditionally and its skip branch
says what it actually means -- built without the loader -- rather than naming a
platform that no longer lacks one. Linux is unchanged and still reports
`platform: NVIDIA CUDA / device: NVIDIA GeForce RTX 4080` on a machine with a
driver.

The Windows half is verified by this repository's `workspace (windows default)`
job, which is the only Windows available to the change.

* fix(compat.opencl): name the Windows import libraries MSVC would have auto-linked

The first Windows section carried upstream's two link libraries and nothing
else, because that is all upstream's CMakeLists names. MSVC never has to name
the rest: its SDK headers pull the default import libraries in through
`#pragma comment(lib, ...)`. mcpp links with lld and does not inherit that.

The build compiled cleanly and failed at link with nine undefined symbols --
eight registry and process-token calls and `StringFromGUID2` -- so advapi32
and ole32 are named here.

Measured on this repository's Windows job, which is the only Windows this
change has. The compile was never the criterion.

Author: Sunrisepeak

pkgs/c/compat.opencl.lua

@@ -28,6 +28,13 @@
 -- hide the GPU. `xim:pocl` therefore declares `OCL_ICD_FILENAMES` into the
 -- subos environment and touches no vendors directory.
 --
+-- WINDOWS ENUMERATES SOMEWHERE ELSE AND NEEDS NO ADAPTER. There the loader
+-- reads `HKLM\SOFTWARE\Khronos\OpenCL\Vendors`, the display adapters through
+-- DXGK, and installed app packages, and each entry names a DLL by absolute
+-- path. An mcpp artifact runs under the SYSTEM loader on Windows, so those
+-- paths resolve with no help -- which is why this platform has a loader here
+-- and no `compat.opencl-runtime` beside it.
+--
 -- SHARED, with the canonical soname, for the reason `compat.vulkan` records:
 -- everything in a process must converge on one loader, and a library that
 -- dlopens `libOpenCL.so.1` by name has to land here.
@@ -59,6 +66,15 @@ package = {
                 sha256 = "48fd0c5181db7cd046f4f731d5955694892e10998d49d09ee0d997e7e04fd939",
             },
         },
+        windows = {
+            ["2026.05.29"] = {
+                url = {
+                    GLOBAL = "https://github.com/KhronosGroup/OpenCL-ICD-Loader/archive/refs/tags/v2026.05.29.tar.gz",
+                    CN     = "https://gitcode.com/mcpp-res/opencl/releases/download/2026.05.29/opencl-2026.05.29.tar.gz",
+                },
+                sha256 = "48fd0c5181db7cd046f4f731d5955694892e10998d49d09ee0d997e7e04fd939",
+            },
+        },
     },
 
     mcpp = {
@@ -153,5 +169,61 @@ package = {
             ldflags = { "-ldl" },
             runtime = { capabilities = { "opencl.icd.driver" } },
         },
+
+        windows = {
+            -- Upstream's WIN32 source list. The loader enumerates drivers from
+            -- the registry (`HKLM\SOFTWARE\Khronos\OpenCL\Vendors`), from the
+            -- display adapters through DXGK, and from installed app packages,
+            -- and loads each with LoadLibrary.
+            --
+            -- NO RUNTIME ADAPTER HERE, AND THAT ASYMMETRY IS THE WHOLE REASON
+            -- LINUX HAS ONE. `compat.opencl-runtime` exists to undo mcpp's
+            -- PRIVATE loader: a bare-soname dlopen from inside an mcpp binary
+            -- does not search the host's library path. A Windows artifact runs
+            -- under the system loader, and the registry names each vendor DLL
+            -- by absolute path, so there is nothing to undo.
+            --
+            -- STATIC, as on macOS, and for a Windows-specific reason on top of
+            -- the one recorded there. A program that wants THE system loader
+            -- links the vendor's `OpenCL.lib` against
+            -- `C:\Windows\System32\OpenCL.dll`; a package shipping a second
+            -- `OpenCL.dll` would compete with that rather than converge on it.
+            -- A program that links this package dispatches through this copy,
+            -- which is the same contract macOS has. It also keeps the module
+            -- definition file out of the build: upstream exports through
+            -- `loader/windows/OpenCL.def`, which only a DLL needs.
+            sources = {
+                "*/loader/windows/icd_windows.c",
+                "*/loader/windows/icd_windows_apppackage.c",
+                "*/loader/windows/icd_windows_dxgk.c",
+                "*/loader/windows/icd_windows_envvars.c",
+                "*/loader/windows/icd_windows_hkr.c",
+                "*/loader/windows/icd_windows_library.c",
+            },
+            -- Upstream's `target_link_libraries(OpenCL PRIVATE cfgmgr32.lib
+            -- runtimeobject.lib)` -- and four more that upstream never has to
+            -- name. cfgmgr32 is the device enumeration the DXGK path walks;
+            -- runtimeobject is WinRT, which the app-package scan calls into.
+            --
+            -- WHY UPSTREAM'S TWO ARE NOT ENOUGH HERE. MSVC pulls the default
+            -- Windows import libraries in through `#pragma comment(lib, ...)`
+            -- in its own SDK headers, so a CMake build never writes advapi32
+            -- or ole32 down. mcpp links with lld and does not inherit that, and
+            -- the build compiled cleanly and then failed at link with nine
+            -- undefined symbols -- eight registry and token calls
+            -- (`RegOpenKeyExA`, `OpenProcessToken`, `GetSidSubAuthority`, ...)
+            -- and `StringFromGUID2`.
+            --
+            -- Measured on this index's own Windows job, which is the only
+            -- Windows the change had: the compile is not the criterion, the
+            -- link is.
+            ldflags = {
+                "-lcfgmgr32",      -- CM_Get_Device_ID_List, the DXGK adapter walk
+                "-lruntimeobject", -- WinRT, for the app-package scan
+                "-ladvapi32",      -- registry + process token
+                "-lole32",         -- StringFromGUID2
+            },
+            runtime = { capabilities = { "opencl.icd.driver" } },
+        },
     },
 }

tests/examples/opencl/mcpp.toml

@@ -2,14 +2,18 @@
 name = "opencl-tests"
 version = "0.1.0"
 
-# The loader and, on Linux, the runtime adapter it depends on. The adapter is
-# what lets the loader's dlopen of a host ICD resolve from inside mcpp's own
-# C library; on a runner with no driver it is empty and the loader reports
-# zero platforms. compat.opencl has no windows entry: Windows drivers are
-# enumerated through the registry, which this index does not model yet, so
-# the test compiles to a skip there.
-[target.'cfg(unix)'.dependencies.compat]
+# The loader on every platform it has one, and on Linux the runtime adapter it
+# depends on. The adapter is what lets the loader's dlopen of a host ICD resolve
+# from inside mcpp's own C library; on a runner with no driver it is empty and
+# the loader reports zero platforms.
+#
+# WINDOWS NEEDS NO ADAPTER AND IS NOT A SKIP ANY MORE. The loader reads the
+# registry, DXGK and app packages there, and each entry names a driver DLL by
+# absolute path that the SYSTEM loader resolves. `compat.opencl` gained its
+# windows section for that reason; the test below is the same source on all
+# three platforms.
+[dependencies.compat]
 opencl = "2026.05.29"
 
-[target.'cfg(unix)'.build]
+[build]
 cxxflags = ["-DHAVE_OPENCL_LOADER=1"]

tests/examples/opencl/tests/platforms.cpp

@@ -14,8 +14,11 @@
 // for the declarations both provide.
 #include <cstdio>
 #if !defined(HAVE_OPENCL_LOADER)
+// Reached only if a consumer builds this file without the loader on the line.
+// It used to be the Windows path, which had no loader to depend on; the
+// package has one now and the manifest declares it on every platform.
 int main() {
-    std::printf("compat.opencl: skipped (no windows entry; drivers are enumerated through the registry there)\n");
+    std::printf("compat.opencl: skipped (built without the loader)\n");
     return 0;
 }
 #else