On Mon, 13 Aug 2018 at 15:55, Peter Dimov via Boost
degski wrote:
I think in all honesty that the whole concept is wrong, clang/llvm on windows should be treated as if it were vc (invoking clang-cl) and not as some spin-off of linux-clang, which seems to amount to try getting a square peg into a round hole. So, we should not have clang-win, but msvc-clang as a target.
That's exactly what clang-win does, it's a msvc-lookalike that uses clang-cl. But it doesn't work. So we use clang-linux, which kind of works, except for dynamic_cast.
I don't care either way, whatever works. In the end of the day, I'd like the linux-clang better as it is far clearer what it does or what it doesn't (and I can look it up consulting the gnu docs), I'm with you here. The dynamic_cast for some weird reason does not work/link, I saw exactly what you saw. Some incantation is just simply wrong. On the other hand, what seems to be lost to everybody (except some clang people) is that clang.exe, clang++.exe, clang-cpp.exe, clang-cl.exe (and the now removed cl.exe in the clang distribution) are just copies of the exact same binary, their hash values confirm this (please check if you doubt what I'm saying). They just behave differently, because they are named differently, I'm sure anyone understands that doing that is not rocket-science, you can do this in C. So passing options to the linux-facade (or the real thing, whatever you'd like to call it) using the -Xclang prefix in clang-cl really just passes flags/parameters to the exact same binary, gnu style. So knowing this, my point is that since vc builds Boost without a problem, clang-cl should build Boost without a problem as well, while nothing stops anyone from passing in other options (directly to "the real thing") using the -Xclang prefix. This is the main reason I don't care, coz I know, it's really the same thing. I also think that this is the main reason the clang-crew is un-responsive, because they know the problem is in the incantations. But, I'm (really) happy we seem be get closer to the problem, at some point we will solve the conundrum. degski -- *"If something cannot go on forever, it will stop" - Herbert Stein*