[Development] Qt 5.9

Jake Petroules Jake.Petroules at qt.io
Wed Nov 23 09:10:36 CET 2016


> On Nov 22, 2016, at 11:56 PM, Alexander Blasche <alexander.blasche at qt.io> wrote:
> 
> 
> 
>> -----Original Message-----
>> From: Development [mailto:development-
>> bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Thiago
>> Macieira
> 
> <snip>
> 
>> Good point. Considering that MSVC 2017 is coming (RC is already out), I'd also
>> be prepared to have it available for 5.9, so I propose:
>> 
>> 5.7 (for comparison, no  change):
>>                32-bit      64-bit
>> MSVC 2013          Y           Y
>> MSVC 2015          Y           Y
>> MSVC 2017          N           N
>> MinGW              Y           N
>> (5 packages)
>> 
>> 5.8:
>>                32-bit      64-bit
>> MSVC 2013          Y           Y
>> MSVC 2015          N           Y
> I am not aware that we are dropping 2015 32bit support in 5.8. I thought the platform/compiler definition for 5.8 was set in stone a long time ago.
> 
>> MSVC 2017          N           N
>> MinGW              Y           Y
>> (5 packages)
>> 
>> 5.9:
>>                32-bit      64-bit
>> MSVC 2013          N           Y
>> MSVC 2015          N           Y
>> MSVC 2017          N           Y
>> MinGW              N           Y
>> (4 packages)
> 
> I don't think we can drop all 32bit support. I do believe MSVC 2017 should be part of the deal though. That's a good suggestion. Keeping these two options in mind, I suggest to drop MSVC 2013 32 bit against MSVC 2017 64bit. This keeps the number of packages the same.

No one suggested dropping *all* 32-bit support just now, but I think we should reduce the number of 32-bit packages now and move towards eliminating them entirely within the next few releases.

> 
>> This also allows us to pick one compiler to provide 32-bit support with if we
>> need to. I just think it's time to let it die and get people who need it to compile
>> from source.
> 
> Compiling Qt from source (especially on Windows) is still a major headache for our customers.

s/customers/users/; this applies to all license types.

Also, I don't think this is a relevant counterargument. Compiling Qt from source statically is a major headache for our users as well, yet we don't provide binary packages for Qt built statically. Let's instead focus on the question of whether 32-bit support is actually relevant to enough of our users to bother spending resources on it.

>> 
>> There are no current Intel 32-bit only CPUs that regular Windows runs on, only
>> legacy. I don't know AMD's product line, but I'd be surprised if it is different.
> 
> The currently sold CPU's are not really the measurement stick here. The measurement stick is actually installed Win 32 systems.

Yes, but what's the 32-bit Windows install base which is capable of running Qt? We only support Windows 7 and above now, so I can't imagine it's very many. Perhaps we should try to find some metrics to base our decision on.

>  
> 
> --
> Alex
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Jake Petroules - jake.petroules at qt.io
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io




More information about the Development mailing list