Andarwinux wrote: > What is the advantage of using clang (not CL)?
For example, when using clang.exe, most clang options are directly accessible without requiring /clang, which is quite convenient. clang-cl/cl only has one official way to specify march: /arch, but this isn't very flexible and is always unconditionally overridden by /clang:-march. Consequently, building some intrinsics often fails because /arch is overridden by -march. A workaround is to manually expand -march into a bunch of options like -mavx and specify /clang:mtune=foo. Overall, clang-cl can be quite strange and cumbersome for users migrating from MinGW to MSVC. With clang and sysroot, build scripts can share most of their logic with linux/mingw without all the tedious setup. Workarounds such as using other filesystems are difficult for CI environments in containers. > We don’t have to do anything in practice, > [Xwin](https://github.com/Jake-Shadle/xwin) is already such a « script » and > it already creates symlinks for all the casing issues and supports the > /winsysroot layout if asked. xwin looks like it needs a bunch of rust stuff to run, which is too bulky for pure C/C++ use cases in CI. > Also see blog post for a practical example: > https://jake-shadle.github.io/xwin/ This will only work for highly integrated, highly constrained build systems like cargo and meson. It often doesn't work for autotools/cmake/pkgconfig. https://github.com/llvm/llvm-project/pull/96417 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
