[Development] QThread::create mandatory in Qt 6?

[Sérgio Martins]

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.martins at 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