Hi,
On 18/11/2020 21:36, Sérgio Martins wrote:
On 2020-11-18 07:34, Oliver Wolff wrote:
Hi
On 16/11/2020 23:29, Sérgio Martins via Development wrote:
On 2020-11-16 21:57, Thiago Macieira wrote:
On Monday, 16 November 2020 13:38:06 PST Cristian Adam wrote:
LLVM.org clang.exe binary reports the x86_64-pc-windows-msvc
target, which
is Clang/MSVC. clang-cl is just a different command line options
parser,
which always sets the *-msvc target.
Clang/MinGW is something that ends up in *-gnu as target. That's
the case
for winlibs and llvm-mingw.
I see, thanks.
So, what's wrong with llvm-mingw?
Probably the prebuilt toolchain Tony is using (WinLibs) has an old
standard library.
The problem is not specific to Clang perse.
But why do we want clang-MinGW to begin with ? MinGW is niche as it
is. I don't see anyone wanting this combo.
clang-MSVC on the other hand is useful as it means a better compiler
frontend (clang) using a better standard library on Windows (msvc).
As far as I know, people *do* want an open alternative that does not
involve Microsoft software. That's where mingw comes into play.
I agree we want MinGW, but we already have it in the CI (gcc-mingw).
clang-mingw won't add much value, as it overlaps a lot with the existing
gcc-mingw.
clang-cl.exe however has a bigger delta over cl.exe.
The question is not about having one more supported Windows
configuration. We do not have the resources to add more and more
configurations to support, so it's more a "replace mingw for Windows
with something else" situation. As there seems to be a need for an open
alternative, it looks like we cannot/should not go the clang-cl way, but
clang-mingw if we replace mingw with a clang toolchain.
As we
cannot support an unlimited amount of configurations, it looks like we
will go the clang-mingw route instead of clang-msvc.
Regards,
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
