On Sun, 12 Aug 2018 at 16:18, Edward Diener via Boost
I do not think these are Boost problems, but clang on Windows problems. Boost.config does identify clang as the compiler on Windows correctly, whether the frontend is VC++ libraries or mingw(-64) libraries.
I'm not saying Boost.Config does not identify Clang on Windows correctly. The problem lies in the various libraries dealing with this information. The build does mention a lot of linux refs though, so even there I'm not so sure. I get things like C:\boost-build\boost\bin.v2\libs\atomic\build\clng-lnx-8.0.0\rls\lnk-sttc . It certainly looks suspicious, but heck 26 libraries do build. We don't all love the broken VC++ emulated preprocessor of clang with
vc++ as you do.
I don't love it, but writing modern C++17 doesn't need much pre-processing, so that's what I try to do. Good. Then I am sure you will be wiling to deal with them when someone
reports problems trying to use clang on Windows with Boost, as Peter has just done. Please tell us what the clang developers tell us about this latest problem. It would be greatly appreciated.
I'm outside the gate too, so no. I've been writing about this for long time now, but it gets mostly ignored. To prove that point: I posted this https://lists.boost.org/Archives/boost/2018/07/242444.php on the 8th of Juli. Nobody answered that and that question has as it turns out yesterday (from a post by that same Peter) to be a very simple answer, thanks Peter!. In the meanwhile I already deleted the stuff to what that was relevant.
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.
Good for you.
? degski -- *"If something cannot go on forever, it will stop" - Herbert Stein*