cmake: fix CMP0194 warning on Windows with MSVC by texasich · Pull Request #21630 · ggml-org/llama.cpp

texasich · 2026-04-08T14:59:22Z

Overview

Fix CMP0194 CMake policy warning when building with MSVC on Windows and CMake 4.1+.

The ggml subproject enables ASM globally via project("ggml" C CXX ASM) for Metal (macOS) and KleidiAI (ARM) backends. On Windows/MSVC, no assembler sources are used, but CMake 4.1+ warns because cl.exe is not a valid ASM compiler.

This sets CMP0194 to NEW before the project() call, guarded by if (POLICY CMP0194) for backward compatibility with older CMake versions. This follows the same pattern used in ggml-vulkan/CMakeLists.txt (CMP0114, CMP0147).

Additional information

Closes #20311

Set CMP0194 policy to NEW before project() call in ggml/CMakeLists.txt to suppress the "MSVC is not an assembler for language ASM" warning introduced in CMake 4.1. The ggml project enables ASM globally for Metal (macOS) and KleidiAI (ARM) backends. On Windows/MSVC, no assembler sources are used, but CMake 4.1+ warns because cl.exe is not a valid ASM compiler. This follows the same pattern used in ggml-vulkan (CMP0114, CMP0147). Closes ggml-org#20311

…)" This reverts commit acc37a4.

oobabooga · 2026-04-15T00:40:26Z

This PR breaks Windows builds with MSVC + Ninja on GitHub runners (windows-2022). After this change, ggml-rpc.dll fails to link because ws2_32 is passed as -lws2_32 (GCC-style) instead of ws2_32.lib.

https://github.com/oobabooga/llama-cpp-binaries/actions/runs/24426437282/job/71361327782

I believe CMP0194 NEW causes CMake to find MinGW on the runner's PATH instead of using MSVC for ASM, which leaks GCC-style linker flags into the whole build.

PR ggml-org#21630 switched CMP0194 to NEW, but that exposed an unfortunate interaction on Windows runners that had MinGW earlier on PATH. CMake ended up selecting MinGW for ASM, and that choice bled GCC-style linker flags into the ggml-rpc.dll link step. The real issue is that we never needed ASM enabled for the whole ggml project in the first place. The only assembly sources involved here live under the KleidiAI path, so advertising ASM at the top level gave CMake more room than it needed to make the wrong compiler choice. This narrows ASM enablement to the KleidiAI block: remove it from project() and call enable_language(ASM) only where those .S files are actually used. Reported-by: oobabooga Refs: ggml-org#21630

ggml-org#21630 added the CMP0194 NEW policy to silence a CMake warning, but on Windows runners it caused CMake to prefer the MinGW toolchain for ASM and broke MSVC builds. Reverting only that policy block restores the previous working behavior. The CMake 4.1+ warning comes back, but that is cosmetic and does not break any platform. Reported-by: oobabooga Refs: ggml-org#21630

JamePeng · 2026-04-15T14:23:14Z

This PR breaks Windows builds with MSVC + Ninja on GitHub runners (windows-2022). After this change, ggml-rpc.dll fails to link because ws2_32 is passed as -lws2_32 (GCC-style) instead of ws2_32.lib.

https://github.com/oobabooga/llama-cpp-binaries/actions/runs/24426437282/job/71361327782

I believe CMP0194 NEW causes CMake to find MinGW on the runner's PATH instead of using MSVC for ASM, which leaks GCC-style linker flags into the whole build.

Same as me,

ggml-org#21630 added the CMP0194 NEW policy to silence a CMake warning, but on Windows runners it caused CMake to prefer the MinGW toolchain for ASM and broke MSVC builds. Reverting only that policy block restores the previous working behavior. The CMake 4.1+ warning comes back, but that is cosmetic and does not break any platform. Reported-by: oobabooga Refs: ggml-org#21630

jjhartmann · 2026-04-18T16:20:12Z

This PR breaks Windows builds with MSVC + Ninja on GitHub runners (windows-2022). After this change, ggml-rpc.dll fails to link because ws2_32 is passed as -lws2_32 (GCC-style) instead of ws2_32.lib.

https://github.com/oobabooga/llama-cpp-binaries/actions/runs/24426437282/job/71361327782

I believe CMP0194 NEW causes CMake to find MinGW on the runner's PATH instead of using MSVC for ASM, which leaks GCC-style linker flags into the whole build.

Same for us as well

#21630 added the CMP0194 NEW policy to silence a CMake warning, but on Windows runners it caused CMake to prefer the MinGW toolchain for ASM and broke MSVC builds. Reverting only that policy block restores the previous working behavior. The CMake 4.1+ warning comes back, but that is cosmetic and does not break any platform. Reported-by: oobabooga Refs: #21630 Co-authored-by: texasich <texasich@users.noreply.github.com>

* cmake: fix CMP0194 warning on Windows with MSVC Set CMP0194 policy to NEW before project() call in ggml/CMakeLists.txt to suppress the "MSVC is not an assembler for language ASM" warning introduced in CMake 4.1. The ggml project enables ASM globally for Metal (macOS) and KleidiAI (ARM) backends. On Windows/MSVC, no assembler sources are used, but CMake 4.1+ warns because cl.exe is not a valid ASM compiler. This follows the same pattern used in ggml-vulkan (CMP0114, CMP0147). Closes ggml-org#20311 * cmake: apply cisc's formatting suggestion --------- Co-authored-by: texasich <texasich@users.noreply.github.com>

ggml-org#21630 added the CMP0194 NEW policy to silence a CMake warning, but on Windows runners it caused CMake to prefer the MinGW toolchain for ASM and broke MSVC builds. Reverting only that policy block restores the previous working behavior. The CMake 4.1+ warning comes back, but that is cosmetic and does not break any platform. Reported-by: oobabooga Refs: ggml-org#21630 Co-authored-by: texasich <texasich@users.noreply.github.com>