Re: [boost] clang-win, again

Subject: Re: [boost] clang-win, again
From: degski (degski_at_[hidden])
Date: 2018-08-13 13:32:06

On Mon, 13 Aug 2018 at 15:55, Peter Dimov via Boost <boost_at_[hidden]>
wrote:

> 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*