Re: [Development] Recommendations for 3rd-party QCH file installation folder for easy discovery?

[Uwe Rathmann]

On Tue, 22 Nov 2016 18:05:20 +0100, Friedrich W. H. Kossebau wrote:

> Q1: what would be a good system path pattern (on *nixoid systems) for
> Qt-based libraries to install their QCH files to?

Qwt ( http://qwt.sf.net ) offers a qch file and is available for quite 
some time. So you could check, what is common practice among distro 
packagers.

F.e. on my box ( OpenSusSE 12.2 ) it is simply not part of qwt6-devel-
doc. But the OpenSuSE package maintainer seems in general not being aware 
of these Qt specific files as the installation of the feature files is 
also broken.

But the rest of the docs can be found below /usr/share/doc/packages/qwt6-
devel-doc and IMO this is where I would expect to find qwt.qch as well.

Maybe other distros can give you a better hint.

> Q2: And would/could there be some way to have 3rd-party QCH files
> automatically added to Qt Assistant, Creator & Co. on installation, to
> spare the user the additional manual step?

To me one of the most error prone things is loading 3rd party plugins to 
the creator. This has mostly to do with binary incompatibilities between 
the libraries used for development and the one used by the Creator 
( Assistant is less bad as being built together with Qt libs ) , but the 
fact, that plugins are loaded "automatically" from some directories is 
part of the problem.

Coming from having experienced maximal user frustration with this 
approach I wouldn't recommend to establish such an automatism.

Uwe


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9

[Tuukka Turunen]

> -Original Message-
> From: Development [mailto:development-
> bounces+tuukka.turunen=qt...@qt-project.org] On Behalf Of Rafael
> Roquetto
> Sent: keskiviikkona 23. marraskuuta 2016 13.37
> To: Jani Heikkinen 
> Cc: development@qt-project.org; releas...@qt-project.org
> Subject: Re: [Development] Qt 5.9
> 
> Hello,
> 
> On Tue, Nov 22, 2016 at 11:42:52AM +, Jani Heikkinen wrote:
> > Hi all,
> 
> > - Start supporting QNX 7.0
> 
> Has the QtC already laid out a plan for what needs to be considered for this? 
> I
> intend to start looking into it soon, but it would be best if we coordinated 
> this
> together in order to avoid duplicated efforts. In particular, we also want to
> properly support QNX 7 on QtCreator, which is orthogonal to having QNX 7
> support on Qt 5.9, timing wise it makes sense.
> 

To some extent, yes. Having proper c++11 support QNX 7 actually makes some 
things easier, while of course we still need to support QNX 6.6 as well. One of 
the first steps is to add QNX 7 to Qt CI system for dev and 5.9 - at least for 
build testing.

There will be many items to tweak and polish, and hope is that you and James 
will participate actively, as discussed at QtCon.

I am well aware the Qt release cycle is a bit quick to keep up with, but hope 
is we will be able to have good support for new QNX 7 already with Qt 5.9.

Yours,

Tuukka

> Thanks,
> Rafael
> 
> --
> Rafael Roquetto | rafael.roque...@kdab.com | 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
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9

[Thiago Macieira]

On quarta-feira, 23 de novembro de 2016 21:14:52 PST Simon Everts wrote:
> > That is not relevant here. I am using Windows 10 (64-bit) but I am still
> > forced (because of 3rt-party-libraries) to develop 32-bit-Qt-applications.
> > Even if the operating system is 64-bit there can be a lot of 32-bit
> > application, e.g. VS 2013 and VS 2015 are still 32-bit applications.
> 
> +1
> 
> As a machine manufacturer we are still deploying 32bit windows systems
> because of this reason. We'll be on 64bit windows soon, but need to support
> the 32bit systems for at least 5 years. A lot of industrial computer
> suppliers still install 32bit images on computers because there aren't any
> 64bit drivers available for the hardware.

Good, thanks for the information, Simon and Helmut.

I know the sample size here is horrible, but in your opinion what compiler 
should we keep offering a 32-bit binary build for?

MSVC 2013
MSVC 2015
MinGW

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9

[Simon Everts]

Op wo 23 nov. 2016 om 11:45 schreef Helmut Mülner :

>
>
> That is not relevant here. I am using Windows 10 (64-bit) but I am still
> forced (because of 3rt-party-libraries) to develop 32-bit-Qt-applications.
> Even if the operating system is 64-bit there can be a lot of 32-bit
> application, e.g. VS 2013 and VS 2015 are still 32-bit applications.
>

+1

As a machine manufacturer we are still deploying 32bit windows systems
because of this reason. We'll be on 64bit windows soon, but need to support
the 32bit systems for at least 5 years. A lot of industrial computer
suppliers still install 32bit images on computers because there aren't any
64bit drivers available for the hardware.

We have no need to create 64bit apps, so its easier to just only create
32bit apps so it's compatible with all systems we need to maintain.

Best regards,
Simon Everts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9

[Rafael Roquetto]

Hello,

On Tue, Nov 22, 2016 at 11:42:52AM +, Jani Heikkinen wrote:
> Hi all,

> - Start supporting QNX 7.0

Has the QtC already laid out a plan for what needs to be considered for
this? I intend to start looking into it soon, but it would be best if we
coordinated this together in order to avoid duplicated efforts. In particular,
we also want to properly support QNX 7 on QtCreator, which is orthogonal to
having QNX 7 support on Qt 5.9, timing wise it makes sense.

Thanks,
Rafael

-- 
Rafael Roquetto | rafael.roque...@kdab.com | 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


smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9

[Konstantin Tokarev]

23.11.2016, 13:26, "Massimo Callegari via Development" 
:
> Hi,
> is there any chance Qt 5.9 can support MSYS2 out of the box ?
>
> For us Linux users, MSYS2 feels like home, and it's the most convenient 
> environment to work with external dependencies simply by using pkg-config.
>
> At the moment, the MSYS2 project is stuck on Qt 5.6.2, I believe mainly cause 
> of QtWebEngine, which AFAIK can't still be built on MSYS2.
> I contributed with some updated patches to build Qt 5.7 but still QtWebEngine 
> is excluded from the build.
>
> Supporting MSYS2 would mean 2 things:
> 1) evaluate the patches that are currently in the GH repo [1] and [2] and 
> check if they're worth to be merged upstream

I'm afraid it does not work in this way. The following process is more likely 
to get desired result:

1. Patch authors who own copyright on the code and understand why each piece is 
needed should contribute patches to codereview.qt-project.org. 

2. When you end up with sane amount of local patches (maybe 3-5) which you 
cannot handle in a step (1), we can discuss it again.

>
> 2) possibly add MSYS2 to the Qt CI system, to deliver a pre-built Qt package 
> in the pkg.tar.xz format suitable for PacMan
>
> Would be nice to finally have QtWebEngine to build on MSYS2 as well.

Revived QtWebKit[1] supports MinGW[2], you can use instead of QtWebEngine for 
some applications

[1] http://qtwebkit.blogspot.ru/2016/08/qtwebkit-im-back.html
[2]actually, it's in a one patch distance from it, will be fixed soon

>
> I can give my assistance in the process, but the content of some patches 
> targeting qtbase is beyond my knowledge of the Qt build files.
> Plus, a lot of work has been done on Qt 5.8.0 in that sense, so probably some 
> things have already been addressed or just need to be lightly adjusted.
>
> Regards,
> Massimo
> [1] https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-qt5 (Qt 
> 5.6.2)
> [2] https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-qt5-git 
> (Qt 5.7.0)
>
> 
> Da: Jani Heikkinen 
> A: "development@qt-project.org" 
> Cc: "releas...@qt-project.org" 
> Inviato: Martedì 22 Novembre 2016 12:42
> Oggetto: [Development] Qt 5.9
>
> Hi all,
> We need to start preparations for Qt5.9 release even Qt 5.8.0 isn't out yet 
> :) There are some things to be agreed already now:
>
> - Qt 5.9.0 Feature Freeze
> - Changes in supported platforms/configurations
>
> So first of all let's agree the feature freeze date: I propose to have the FF 
> 1.2.2017. From the history we can see that time needed from FF to final 
> release is (even more than) 17 weeks. I know it is too long time but at the 
> moment that is the fact and there is no evidence that we can do it within 
> shorter schedule. We are trying to find ways to make it shorter but at the 
> moment there isn't any big improvements coming and so on that 17 weeks is the 
> best base for our plans. So if we want to get Qt 5.9.0 release out before 
> summer holidays we need to have ff at the beginning of February.
>
> And note: At this time we want to keep the FF date to be able to keep the 
> schedule. That means there won't be any exceptions: If feature isn't ready 
> and in at FF date then it won't be in Qt 5.9 release. So please make sure all 
> new features are in early enough & those are fulfilling the ff requirements: 
> https://wiki.qt.io/Qt_5_Feature_Freeze
>
> Then I propose following changes in supported platforms/configurations:
>
> - We have earlier agreed that for Apple we will support three latest 
> versions. So this means
>    * For macOS we drop 10.9 and support 10.10, 10.11 & 10.12
>    * For iOS we drop 7.x and support 8.x, 9.x, 10.x
>
> - I propose to drop standalone macOS Android installer; One having iOS & 
> Android should be enough
>
> - For MinGW I propose to start delivering 64 bit binary packages instead of 
> 32 bit one & start using MinGW 6.x (6.2?)
>
> - For Windows Android I propose to start doing Android Windows build with 
> MinGW53 (if we are able to build it. Otherwise MinGW49 will be used as with 
> 5.8)
>
> - For WinRT/WinPhone I propose to drop WinRT 8.1 and WinPhone 8.1 support & 
> start using term UWP (Universal Windows platform). It means also dropping 
> msvc 2013 from WinRT/WinPhone; UWP only supports msvc2015
>
> - Start supporting QNX 7.0
>
> br,
>
> Jani Heikkinen
> Release Manager
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org

Re: [Development] Qt 5.9

[Helmut Mülner]

> Von: Development
[mailto:development-bounces+helmut.muelner=gmail@qt-project.org] Im
Auftrag von Thiago Macieira
> Gesendet: Mittwoch, 23. November 2016 09:22

> On quarta-feira, 23 de novembro de 2016 08:10:36 PST Jake Petroules wrote:
> > > 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.

> That's an important point: since Qt 5.7, we no longer support anything
older than Windows 7. 

> That was the first Windows with decent 64-bit support and computers with
Windows 7, 8, 8.1 and now 10 tended
>  to come with the 64-bit version pre-installed.

>  So the chances of users running 64-bit Windows are much higher now.

> We only have to contend with pre-2007 computers that have been upgraded
since. 
> And netbooks, since many of the first and second generation Atom came with
their 64-bit capabilities fused off.

 > (Ultrabooks are always 64-bit and actually use Core processors, not Atom)

That is not relevant here. I am using Windows 10 (64-bit) but I am still
forced (because of 3rt-party-libraries) to develop 32-bit-Qt-applications.
Even if the operating system is 64-bit there can be a lot of 32-bit
application, e.g. VS 2013 and VS 2015 are still 32-bit applications.

Helmut Mülner


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Qt 5.7.1 packages available

[Akseli Salovaara]

Hi all,

We have most likely final Qt 5.7.1 snapshot available

Linux: http://download.qt.io/snapshots/qt/5.7/5.7.1/579/ 
Mac: http://download.qt.io/snapshots/qt/5.7/5.7.1/617/ 
Windows: http://download.qt.io/snapshots/qt/5.7/5.7.1/664/
Src: http://download.qt.io/snapshots/qt/5.7/5.7.1/latest_src/ 

According to RTA smoke testing packages seems to be OK so please test the 
packages as soon as possible. All known blockers should be fixed, please verify 
fixes for open ones ( https://bugreports.qt.io/issues/?filter=17833 ). We will 
release these packages as Qt 5.7.1 later (maybe next Tuesday) if nothing really 
serious found during testing.

Please update the known issues page when needed: 
https://wiki.qt.io/Qt_5.7.1_Known_Issues 

Known issues in the packages: https://bugreports.qt.io/issues/?filter=18129 

Br,
Akseli

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9

[Massimo Callegari via Development]

Hi,
is there any chance Qt 5.9 can support MSYS2 out of the box ?

For us Linux users, MSYS2 feels like home, and it's the most convenient 
environment to work with external dependencies simply by using pkg-config.

At the moment, the MSYS2 project is stuck on Qt 5.6.2, I believe mainly cause 
of QtWebEngine, which AFAIK can't still be built on MSYS2.
I contributed with some updated patches to build Qt 5.7 but still QtWebEngine 
is excluded from the build.


Supporting MSYS2 would mean 2 things:
1) evaluate the patches that are currently in the GH repo [1] and [2] and check 
if they're worth to be merged upstream

2) possibly add MSYS2 to the Qt CI system, to deliver a pre-built Qt package in 
the pkg.tar.xz format suitable for PacMan


Would be nice to finally have QtWebEngine to build on MSYS2 as well.

I can give my assistance in the process, but the content of some patches 
targeting qtbase is beyond my knowledge of the Qt build files.
Plus, a lot of work has been done on Qt 5.8.0 in that sense, so probably some 
things have already been addressed or just need to be lightly adjusted.

Regards,
Massimo
[1] https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-qt5 (Qt 
5.6.2)
[2] https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-qt5-git (Qt 
5.7.0)



Da: Jani Heikkinen 
A: "development@qt-project.org"  
Cc: "releas...@qt-project.org" 
Inviato: Martedì 22 Novembre 2016 12:42
Oggetto: [Development] Qt 5.9


Hi all,
We need to start preparations for Qt5.9 release even Qt 5.8.0 isn't out yet :) 
There are some things to be agreed already now:

- Qt 5.9.0 Feature Freeze
- Changes in supported platforms/configurations

So first of all let's agree the feature freeze date: I propose to have the FF 
1.2.2017. From the history we can see that time needed from FF to final release 
is (even more than) 17 weeks. I know it is too long time but at the moment that 
is the fact and there is no evidence that we can do it within shorter schedule. 
We are trying to find ways to make it shorter but at the moment there isn't any 
big improvements coming and so on that 17 weeks is the best base for our plans. 
So if we want to get Qt 5.9.0 release out before summer holidays we need to 
have ff at the beginning of February.

And note: At this time we want to keep the FF date to be able to keep the 
schedule. That means there won't be any exceptions: If feature isn't ready and 
in at FF date then it won't be in Qt 5.9 release. So please make sure all new 
features are in early enough & those are fulfilling the ff requirements: 
https://wiki.qt.io/Qt_5_Feature_Freeze

Then I propose following changes in supported platforms/configurations:

- We have earlier agreed that for Apple we will support three latest versions. 
So this means
   * For macOS we drop 10.9 and support 10.10, 10.11 & 10.12
   * For iOS we drop 7.x and support 8.x, 9.x, 10.x

- I propose to drop standalone macOS Android installer; One having iOS & 
Android should be enough

- For MinGW I propose to start delivering 64 bit binary packages instead of 32 
bit one & start using MinGW 6.x (6.2?)

- For Windows Android I propose to start doing Android Windows build with 
MinGW53 (if we are able to build it. Otherwise MinGW49 will be used as with 5.8)

- For WinRT/WinPhone I propose to drop WinRT 8.1 and WinPhone 8.1 support & 
start using term UWP (Universal Windows platform).  It means also dropping msvc 
2013 from WinRT/WinPhone; UWP only supports msvc2015

- Start supporting QNX 7.0

br,

Jani Heikkinen
Release Manager
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9

[Jake Petroules]

> On Nov 23, 2016, at 1:49 AM, Tim Blechmann  wrote:
> 
> hi all,
> 
 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.
>> 
>> That's an important point: since Qt 5.7, we no longer support anything older 
>> than Windows 7. That was the first Windows with decent 64-bit support and 
>> computers with Windows 7, 8, 8.1 and now 10 tended to come with the 64-bit 
>> version pre-installed. So the chances of users running 64-bit Windows are 
>> much 
>> higher now.
> 
> when using qt inside a plugin it is not necessarily a question how many
> users are on 64-bit windows, but how many are on 64-bit hosts, as 32-bit
> host can run on 64-bit windows.

True, and this is a good point. Many Windows applications are still 32-bit.

> 
> i don't care about the binary packages, though. as long as i can still
> build from sources, i'm fine ... but please don't completely drop
> support for 32-bit windows.

Of course this is out of the question (and would be of little to no benefit to 
Qt). We're talking ONLY about binary packages here, not to worry. :)

> 
> cheers,
> tim
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9

[Tim Blechmann]

hi all,

>>> 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.
> 
> That's an important point: since Qt 5.7, we no longer support anything older 
> than Windows 7. That was the first Windows with decent 64-bit support and 
> computers with Windows 7, 8, 8.1 and now 10 tended to come with the 64-bit 
> version pre-installed. So the chances of users running 64-bit Windows are 
> much 
> higher now.

when using qt inside a plugin it is not necessarily a question how many
users are on 64-bit windows, but how many are on 64-bit hosts, as 32-bit
host can run on 64-bit windows.

i don't care about the binary packages, though. as long as i can still
build from sources, i'm fine ... but please don't completely drop
support for 32-bit windows.

cheers,
tim


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9

[Maurice Kalinowski]

> > - For WinRT/WinPhone I propose to drop WinRT 8.1 and WinPhone 8.1
> support & start using term UWP (Universal Windows platform).  It means also
> dropping msvc 2013 from WinRT/WinPhone; UWP only supports msvc2015
> 
> Absolutely agree.
[Kalinowski Maurice] 
Start using the term UWP in our website etc. WinRT is still a technical correct 
term for the API. So we should not start simply renaming mkspecs or such.

In addition this causes a couple of changes to our CI system. My proposal would 
be:

- Have winrt-x86-msvc2015 (or winrt-x64-msvc2015) replace the 
winphone-arm-msvc2013 test target on CI. Right now this would be the same build 
test, but I still hope that CI resources will allow regular CI auto tests at 
one point
- Have winrt-arm-msvc2015 replace winrt-x86-msvc2015 replace to be tested 
during qt5.git integration. Currently Windows 10 (UWP) is only tested for the 
integration due to resource constraints. It should not get worse when we are 
removing platforms.

BR,
Maurice
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9

[Maurice Kalinowski]

> On quarta-feira, 23 de novembro de 2016 08:10:36 PST Jake Petroules wrote:
> > > 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.
> 
> That's an important point: since Qt 5.7, we no longer support anything older
> than Windows 7. That was the first Windows with decent 64-bit support and
> computers with Windows 7, 8, 8.1 and now 10 tended to come with the 64-
> bit version pre-installed. So the chances of users running 64-bit Windows are
> much higher now.
> 
[Kalinowski Maurice] 
This is only true for the desktop case. Especially those cheap tablets with 
Windows 10 in the ~100Euro area still have Windows 10 32bit included. That 
touches a pretty big consumer area.

Also note, that those is only for classic app development. For WinRT we still 
need x86 packages, because first x86 packages should be part of the bundle, and 
secondly the x86 build can be (and actually is) used for the Windows 10 
(Mobile) emulators in addition .

BR,
Maurice
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9

[Thiago Macieira]

On quarta-feira, 23 de novembro de 2016 07:56:00 PST Alexander Blasche wrote:
> > 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.

This is a proposal. In order to keep the work the same, I decided to drop one 
MSVC 32-bit to make room for MinGW 64-bit. To answer Konstantin: I thought it 
was more likely people were still using 32-bit when they hadn't yet upgraded 
their compilers. This is an unproven guess.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9

[Thiago Macieira]

On quarta-feira, 23 de novembro de 2016 08:10:36 PST Jake Petroules wrote:
> > 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.

That's an important point: since Qt 5.7, we no longer support anything older 
than Windows 7. That was the first Windows with decent 64-bit support and 
computers with Windows 7, 8, 8.1 and now 10 tended to come with the 64-bit 
version pre-installed. So the chances of users running 64-bit Windows are much 
higher now.

We only have to contend with pre-2007 computers that have been upgraded since. 
And netbooks, since many of the first and second generation Atom came with 
their 64-bit capabilities fused off. (Ultrabooks are always 64-bit and 
actually use Core processors, not Atom)

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Summary ABI compabilty

[Lars Knoll]

I think we are mixing two problems that should be handled separately in this 
whole thread.

The first one is the question how much of libstdc++ we want to use and expose 
in our APIs. The second question is about our BC promise between minor and 
patch level releases. Let's keep these two questions separated and don't mix 
those in the discussions.

There are a lot of good arguments towards using the STL and libstdc++ more, as 
it will allow us to interoperate better with the C++ standard, and provides a 
couple of things that we really want to use. So I can see many good arguments 
towards going down that route. Doing so will bind the compiled Qt binary to a 
certain version of that library (ie, it will require a recompile of Qt to 
switch from libc++ to libstdc++). To a large extent that is no different than 
the situation we're facing with e.g. different VC++ runtimes. It also doesn't 
create impossible challenges for the Linux packagers/distributors (or at least 
the challenges won't be caused by us). So I'm positive towards using more of 
the standard functionality and APIs (and also exposing them in our APIs). 

Breaking BC in Qt minor or patch level releases is a totally different 
question. So far I have not convincing arguments as to why we would gain a lot 
here. We've managed for years to fix our bugs and introduce new features 
without breaking BC, I don't see why this should be different now. We will have 
a well defined point where we can break BC with Qt 6 and I think it's 
beneficial to have these breakages only at well defined points. Let's also not 
forget that breaking BC in minor releases would come at a severe cost for the 
Linux ecosystem, an ecosystem we want to support as good as we can.

Cheers,
Lars

I think this is something we probably just need to do, as we see more

As we all know there are quite a few things we really would like to use

On 23/11/16 01:05, "Development on behalf of Thiago Macieira" 
 wrote:

On quarta-feira, 23 de novembro de 2016 00:07:35 PST Allan Sandfeld Jensen 
wrote:
> Can't we statically link to it, so that it doesn't matter which version 
the
> application is using?

No, same problem, which is exactly what the Linux distros are doing wrong.

C++ requires certain symbols to be shared and obey ODR: the typeinfo for 
the 
base types and the virtual tables for some classes (notably, 
std::exception). 
If we statically link one of the libraries that contains those, then 
applications may or may not link to them at runtime. Breaking ODR for those 
is 
problematic.

The solution is simple: we need to dynamically link to a library that 
provides 
those and just those. Both libc++ and libstdc++ have such a library: 
respectively, libc++abi and libsupc++. Linux distros need to make sure that 
only one of those exists and that both libc++ and libstdc++ link to it.

But even if we do that, it doesn't solve the problem of using the std types 
in 
our ABI, like std::function which we desperately want to use. If our 
objective 
is to do that, then you can't replace.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9

[Jake Petroules]

> On Nov 22, 2016, at 11:56 PM, Alexander Blasche  
> wrote:
> 
> 
> 
>> -Original Message-
>> From: Development [mailto:development-
>> bounces+alexander.blasche=qt...@qt-project.org] On Behalf Of Thiago
>> Macieira
> 
> 
> 
>> 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@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9

[Lars Knoll]

I'm fine with this one as well, but as Thiago said in that case it would be 
good if we could provide 64bit MingW for 5.8 (maybe 5.8.1) to give people a 
little more time to migrate.

Cheers,
Lars

On 23/11/16 08:59, "Development on behalf of Alexander Blasche" 
 wrote:

> -Original Message-
> From: Development [mailto:development-
> bounces+alexander.blasche=qt...@qt-project.org] On Behalf Of Alexander
> Blasche
 
> 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.

To make it more obvious here is my suggestion:

5.9:
32-bit  64-bit
MSVC 2013  N   Y
MSVC 2015  Y   Y
MSVC 2017  N   Y
MinGW N   Y

--
[Alexander Blasche] Alex
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development