Hi,
How to configure cmake on Windows to use clang-cl with ninja multi config for intel 32 bits, intel 64 bits and arm64 bundled with Visual Studio?
Thank you very much!
1 Like
Each of those will need a separate build tree. CMake’s multi config is about flag selection more than anything else. There’s still only a single toolchain allowed for a given language per build. If the toolchain supports fat binaries (e.g., macOS), then the compiler can be told to write multiple architectures at once, but AFAIK, Windows does not support such things.
I believe what you want is possible using Ninja + VS + CMake:
Unfortunately, no. What OP is asking is whether it’s possible to use different compilers in a single Ninja Multi-Config build directory, which it is not. You can of course always create separate build directories with different compilers.
CMakePresets.json is great for storing the settings for different compilers, but it won’t allow different compilers in the same build directory.
Oh I didn’t realize he was asking to using multiple compilers with the same build directory. Yeah that isn’t possible.
I thought the question was how to use clang-cl for x86, x64, and arm64.
Hello, thake you for your help.
I always planed to have 3 directories:
- cmake-builds/x86
- cmake-builds/x86_64
- cmake-builds/aarch64
My main issue was that I needed to start a visual studio prompt first and then it could only configure correctly one target for example the x86_64 if I started the intel 64 bits prompt, but then it would not configure correctly the intel 32 bits build directory and use the 64 bit compiler instead.
Ah. Yes, the Ninja generator requires a loaded compiler environment. FWIW, this is the same on other platforms (modules on Unix, DEVELOPER_DIR on Xcode). These platforms also tend to have toolchains that just work out of the box, but there’s not much to be done about that. There’s no plan to change that because there’s no way to have ninja reexec from build.ninja with the right environment (or any other generator that doesn’t itself know how to use the right toolchain as the IDE generators do).
This makes the visual studio back-end much more convenient. Because I just load the intel 64 bits environment and I can configure which architecture I want from it.
By the way we do compile using cmake --build so we would not require ninja to reexec ninja.
Also when we configure cmake, doesn’t cmake use absolute path to the tools?
There’s no way to force execution through cmake --build, so it’s not a solution either.
While true, the MSVC toolchains bring in the system include paths and other things through the environment; they’re not baked into the compiler or automatically derived from the compiler’s location.
Thank you very much Ben for all those details!
How would it work then for VSCode to switch from one build directory (arm) to another (x86_64)?
Would I need to ensure that I have the right environment variables?
To me it would be amazing to rely upon cmake --build to wrap ninja execution and make sure the environment is correct.
I’ve more of a Linux background and for me it is very difficult to work on Windows.
No idea. Personally, I generally edit on my main machine and use git to pull code back down on Windows when doing development iterations.
Unfortunately, the stable interface is vcvarsall.bat, so CMake would have to start cmd to execute that and either have that run ninja or somehow extract the environment settings out of it. With such a…poorly defined interface, getting CMake to do this is not really feasible.
You’re not the only one 
. I would recommend using PowerShell and something like this script to get information from vcvarsall.bat.
1 Like