Re: QGIS 2.14 & Qt5
Hi
On 03/11/2016 06:00 PM, Sebastiaan Couwenberg wrote:
> Hi Dmitry,
>
> Thanks for the feedback.
>
> On 11-03-16 16:01, Dmitry Shachnev wrote:
>> On Sat, Feb 27, 2016 at 05:13:37PM +0100, Sebastiaan Couwenberg wrote:
>>> The first build of 2.14 with Qt5 failed due to errors in the
>>> spatialite provider ('DetachFromResultSet' is not a member of
>>> 'QSqlResult'), this looks like an incompatibility with
>>> libqt5sql5(-sqlite).
>> That's https://code.qt.io/cgit/qt/qtbase.git/commit/?id=fc15a1d5e2cb064d.
>>
>> You may steal the changes to qsql_sqlite.{cpp,h} from that commit and
>> apply them to your qsql_spatialite.{cpp,h} files — they are very small.
> It looks like that switches to the new Qt5 method losing backwards
> compatibility with Qt4. Since QGIS 2.16 will support dual Qt4/Qt5, we
> should ifdef that to support both. For Debian we need that too for the
> backports which will keep using Qt4 in jessie, otherwise we'll need a
> bunch of Qt5 backports.
Hmm... I wonder why I didn't run into that. I have built several Qt5
builds already (it's in our continuous integration setup for the last
couple of hours even) and I didn't run into that. Maybe because of some
different cmake flags...
If you have any compatibility patches, please make a pull request, I'll
be happy to merge them. I've already included some #ifdef's and I don't
mind adding some more.
>
>>> The second build failed due to errors in the globe plugin because
>>> it doesn't have /usr/include/x86_64-linux-gnu/qt5/QtOpenGL in its
>>> include path for QGLWidget, the Globe plugin has likewise been
>>> disabled. The third build failed due to errors in QGIS server because
>>> QtNetwork/QFtp is no longer available in Qt5, also disabled for now.
>>> These changes allow the build to succeed with Qt5.
>> If we package https://code.qt.io/cgit/qt/qtftp.git/, will it help you?
> I think it will help.
>
> I've added Matthias Kuhn to the CC who has been doing a lot of Qt5 work
> in QGIS upstream. I hope he can give a better answer what they need from
> Qt5 packagers.
I noticed the same and mentioned it here, but there has been no response
yet.
https://github.com/qgis/QGIS/pull/2896
I hope Alessandro Pasotti or Marco Hugentobler (in CC) who are more
involved and author of that code can shed some light here. We will have
to find a cross-platform method of fixing this code. So either we will
have to replace it with another functionality than QFtp or ship it
within our code.
>>> Because packages in unstable will be synced into Ubuntu I don't want a
>>> severely feature reduced qgis in Debian unstable just to close the RC
>>> bug. I'd rather downgrade the severity to important as long as the new
>>> python-qt4 without the Webkit module hasn't been uploaded to unstable.
>> Yeah, it's my fault that the new python-qt4 hasn't yet been uploaded.
>> But it will be definitely in Stretch (as we want to get qtwebkit removed
>> for Stretch).
> While I would like to get the new QGIS 2.14 LTR into jessie-backports, I
> think we'll have to keep it in unstable only for the time being. We
> should be able to switch to Qt5 with QGIS 2.16, expected to be released
> 24 June 2016.
>
>> Also, Ubuntu is now in a sync freeze, so no autosyncs will happen until
>> the 16.04 release.
> The xenial release is scheduled for April 21st, so I expect autosyncs to
> happen again by the end of April too. There will only be a two month gap
> until the QGIS 2.16 release. So if they drop Qt4WebKit at the start of
> the cycle, we should be able to get
>
>>> I should probably file bugs for the Qt5 related build failures if they
>>> haven't been reported yet.
>> If you need any help with Qt 5 porting, please contact me :)
> Thanks for the offer, it's much appreciated. I'm very able to help with
> the porting effort, but I try to do what I can. I haven't been able to
> sit down and look into the Qt5 issues again, but the issue with the
> globe plugin may be easy to fix. The CMakeLists.txt already uses
> find_package(Qt5OpenGL), but /usr/include/x86_64-linux-gnu/qt5/QtOpenGL
> is not added to the include paths. Adding Qt5OpenGL_INCLUDE_DIRS to
> include_directories for the plugin may be sufficient.
Please open pull requests for anything you find there as well. But from
my experience with you, I do not have to even mention this :-)
>
> I hope to find time soon to look into the Qt5 issues more extensively.
> Getting the Python bindings to build with Qt5 is most important,
> preferably without having to switch to Python 3 at the same time.
In theory there are two different switches. But I haven't tried toggling
them individually. And then there is even more fun when it comes to
pyqt4-qt4, pyqt4-qt5, pyqt5-qt5 and all these combined with different
python versions.
Kind Regards
--
Matthias Kuhn
OPENGIS.ch - https://www.opengis.ch
Spatial • (Q)GIS • PostGIS • Open Source
Reply to: