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.
As we
cannot support an unlimited amount of configurations, it looks like we
will go the clang-mingw route instead of clang-msvc.
Regards,
--
Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
