On Sun, 12 Aug 2018 at 14:56, Edward Diener via Boost
When using clang-cl the vc++ compiler is the backend.
We must be living in parallel worlds. If you use Clang/LLVM, LLVM is obviously the backend. If you download and install https://releases.llvm.org/6.0.1/LLVM-6.0.1-win64.exe the backend is LLVM. BUT, and that's where trouble (in relation to Boost) starts, is that it will use the VC STL. There is AFAICS no particular problem with the VC STL (I'm talking current release here, 15.7.6), but there is, with the way Boost deals with it when invoked with clang as a compiler on windows (non mingw), particularly boost/type_traits, has problems. Clang signals f.e. (as it did over a year ago) is_assignable not found, did you mean std::is_assignable, YES I DO. I found this issue today, Boost.Wave does not compile because of this and so don't do 9 other libraries. I've written to the list about this issue in boost/type_traits in detail over a year ago (from memory). It is possible to
use clang with mingw(-64)/gcc as the backend on Windows. In either case clang has almost always exhibited its problems in the linking stage rather than the compiler stage due to the fact that it sometimes mismatches the names it creates with the backend compiler's libraries it uses. In one case on Windows, attempting to run the VMD tests, it fails pretty miserably in the preprocessor stage whereas mingw(-64)/gcc succeeds completely.
Why would you even like to do that, LLVM generates native code directly (as it does for Rust). Both link (the vc exe, but not with LTCG, or llvm lto, thin or full) and lld will work (lld also with lto, thin or full, if you compile the code with the correct flags). There's no reason to believe (or a need for that) it works with mingw/gcc, AFAICS. Clang is a compiler, it does not do any name matching (it eats a cpp-file and spits out LLVM-ir), the problems must be in the rest of the (your) tools. I gave up trying to get the clang developers to pay any attention to any of
this a while ago.
They are a gated community just like Boost and respond similarly, just feel welcomed and all is good. Even building clang on Windows has been problematical for a while now
and past appeals to clang developers about this have resulted in silence on their end of things.
I use clang/cmake/ninja, and it works AFAICS. That's what they guarantee, Clang/LLVM should build with Clang stable (the one from the download link), that's it, no more. vcpkg has llvm (including clang) as well, by the way, so if you don't want to download, or would like to add your own flavour, knock yourself out. There is also some stuff (just look it up on llvm.org) to bootstrap clang with vc and then (totally automated) build clang with the clang you just built. This works, I tried it (and succeeded) 3 days ago. Getting clang to work on Windows has been very
low priority for their developers in the past. Others can spend time reporting problems about their Windows implementation to clang developers if they want, but I have given up that cause.
It seems they are very focused on the compiler and not on any tooling. Having said that, it works perfectly fine from where I'm standing. I use clang/llvm with VS17 on a daily basis without any issue, which is unsurprising [but great] as MS uses clang to check how their STL is doing. degski -- *"If something cannot go on forever, it will stop" - Herbert Stein*