[osg-users] Linux packaging: Qt 4 vs 5

[Stuart Mentzer]

Hello,

The OpenSceneGraph-qt/-devel (OSG 3.4.0) packages on Fedora 24 are built against Qt 4. I'm wondering if that is suggested by OSG (maybe due to the single thread restriction on Qt 5) or is the choice of the Fedora packager.

I am able to run our OSG applications with Qt 5 on Windows and I'd like to try it on Linux to see if we can transition off Qt 4. Would it make sense to request OpenSceneGraph-qt5 packages be added by the main distros? (I am assuming those are the only OSG packages with Qt dependencies.) If so, how best to do that?

Thanks,
Stuart

[Alberto Luaces]

Hi Stuart,

Stuart Mentzer writes:

> Hello,
>
> The OpenSceneGraph-qt/-devel (OSG 3.4.0) packages on Fedora 24 are
> built against Qt 4. I'm wondering if that is suggested by OSG (maybe
> due to the single thread restriction on Qt 5) or is the choice of the
> Fedora packager.
>

I think the main reason is to support existing code using OSG and Qt4 on
their repositories. However, I expect all distributions to begin
shipping OSG and Qt5 since Qt4 is fading away.

>
> I am able to run our OSG applications with Qt 5 on Windows and I'd
> like to try it on Linux to see if we can transition off Qt 4. Would it
> make sense to request OpenSceneGraph-qt5 packages be added by the main
> distros? (I am assuming those are the only OSG packages with Qt
> dependencies.) If so, how best to do that?

Personally I think that it would make sense. You would usually file a
bug report against the OSG package. For example, Debian has a
"wish-list" category for that kind of petitions. You could also address
the maintainer personally.

--
Alberto

_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[François Cami]

Hi,

On Fri, Jul 15, 2016 at 9:15 AM, Alberto Luaces <alu...@udc.es> wrote:
> Hi Stuart,
>
> Stuart Mentzer writes:
>
>> Hello,
>>
>> The OpenSceneGraph-qt/-devel (OSG 3.4.0) packages on Fedora 24 are
>> built against Qt 4. I'm wondering if that is suggested by OSG (maybe
>> due to the single thread restriction on Qt 5) or is the choice of the
>> Fedora packager.
>>
>
> I think the main reason is to support existing code using OSG and Qt4 on
> their repositories. However, I expect all distributions to begin
> shipping OSG and Qt5 since Qt4 is fading away.

In some cases it is worth maintaining two versions of the same
library, but yes, the Qt4 build will go away sooner than later.

>> I am able to run our OSG applications with Qt 5 on Windows and I'd
>> like to try it on Linux to see if we can transition off Qt 4. Would it
>> make sense to request OpenSceneGraph-qt5 packages be added by the main
>> distros? (I am assuming those are the only OSG packages with Qt
>> dependencies.) If so, how best to do that?
>
> Personally I think that it would make sense. You would usually file a
> bug report against the OSG package. For example, Debian has a
> "wish-list" category for that kind of petitions. You could also address
> the maintainer personally.

The Fedora procedure would be to file a bug at https://bugzilla.redhat.com.
You can try to email OpenSceneG...@fedoraproject.org afterwards.

François

[Robert Osfield]

Hi Qt'ers,

I feel the Qt4 vs Qt5 issues really require use to have two separate
libs built i.e. osgQt4 and osgQt5. With 3rd party applications
currently depending upon a osgQt header the distro's that depend upon
this will obviously prefer to maintain a osgQt header and osgQt lib
name. Would it be possible to use symbolic links from osgQt to osgQt4
or osgQt5?

On the OSG source code side we could have two separate Qt NodeKits
within the main repository or play games with building the same source
several times with different build options and install targets. Even
this route doesn't really solve the wider problem that Qt and OSG rev
at different rates.

Longer term I think the right solution is to spin out osgQt from the
core OSG and maitain osgQt or two separate osgQt4 and osgQt5 projects
and have this maintained by Qt experts in the OSG community rather
than myself who only a small amount of experience with Qt.

Potentially we could spin out osgQt for 3.6. It's short notice, but
removing things from the core OSG is low risk for the OSG itself, it
just requires a bit of work from the community and myself to set up
the osgQt/osgQt4/osgQt5 NodeKit so it can live long and prosper
outside the core OSG.

Would anyone like to get involved on the osgQt side?

Robert.

[Stuart Mentzer]

> On Fri, Jul 15, 2016 at 9:15 AM, Alberto Luaces <alu...@udc.es> wrote:
>>> I am able to run our OSG applications with Qt 5 on Windows and I'd
>>> like to try it on Linux to see if we can transition off Qt 4. Would it
>>> make sense to request OpenSceneGraph-qt5 packages be added by the main
>>> distros? (I am assuming those are the only OSG packages with Qt
>>> dependencies.) If so, how best to do that?
>> Personally I think that it would make sense. You would usually file a
>> bug report against the OSG package. For example, Debian has a
>> "wish-list" category for that kind of petitions. You could also address
>> the maintainer personally.
> The Fedora procedure would be to file a bug at https://bugzilla.redhat.com.
> You can try to email OpenSceneG...@fedoraproject.org afterwards.

Done for Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1357109

From https://packages.debian.org/experimental/openscenegraph-3.4 and https://www.archlinux.org/packages/community/x86_64/openscenegraph/ it looks like 3.4.0 is built against Qt5 in Debian and Arch, excluding building applications with Qt4, which isn't desirable either. Having distinct osgQt 4 and 5 packages as Robert describes seems like the best way to encourage packagers to provide them both (even if most of the differences are in the examples).

> François
> _______________________________________________
> osg-users mailing list
> osg-...@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Stuart

[James Turner]

> On 15 Jul 2016, at 10:45, Robert Osfield <robert....@gmail.com> wrote:
>
> Longer term I think the right solution is to spin out osgQt from the
> core OSG and maitain osgQt or two separate osgQt4 and osgQt5 projects
> and have this maintained by Qt experts in the OSG community rather
> than myself who only a small amount of experience with Qt.
>
> Potentially we could spin out osgQt for 3.6. It's short notice, but
> removing things from the core OSG is low risk for the OSG itself, it
> just requires a bit of work from the community and myself to set up
> the osgQt/osgQt4/osgQt5 NodeKit so it can live long and prosper
> outside the core OSG.
>
> Would anyone like to get involved on the osgQt side?

I’ve been working on improving the Qt5 integration with OSG in a local fork; one of the reasons I’ve hesitated about submitting it here is that it would be entirely incompatible with the current Qt4-based code in osgQt.

I’m happy to ‘get involved’, but I don’t feel qualified to take ownership of the broken-out osgQt code, I’d want someone who knows OGS much more deeply, and who is more involved in the community here, to manage that.

Kind regards,
James

[Stuart Mentzer]

The Fedora OSG packager added this comment to the Bugzilla entry:


> Having experimented a bit with Qt4/Qt5 builts, I found this won't be easily achievable.
>
> - OSG-3.4.0's qt-libs/plugins/binaries use non-qt-versioned file names/SONAMEs. I.e. qt4 and qt5-compiled binaries will conflict at runtime/installation time.
>
> - Qt5-built OSG is slightly incompatible with Qt4-build versions of OSG-3.4.0.
> (Building against QT5 causes OSG to drop the osgdb_qfont.so plugin)
>
> - OSG-3.4.0 monolytical [monolithic?] build system treats QT4 and QT5 as mutually exclusive alternatives.
>
> All in all, I don't see an easy way to implement parallel installation of qt4-/qt5-build variants.


If these issues can't be finessed, separating just osgQt into Qt 4 and 5 packages won't suffice: we'll need separate OSG builds, installation paths, and library naming. But maybe someone more familiar with Linux builds can see a simpler approach. Having both Qt 4 and 5 builds on Linux seems to have value but if that's not practical it might be time with OSG 3.6.0 to encourage Linux packagers to switch to Qt 5.

Stuart[/quote]

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=68162#68162

[Robert Osfield]

Hi Stuart,

On 18 July 2016 at 18:24, Stuart Mentzer <osgf...@tevs.eu> wrote:
> The Fedora OSG packager added this comment to the Bugzilla entry:
>
>
>> Having experimented a bit with Qt4/Qt5 builts, I found this won't be easily achievable.
>>
>> - OSG-3.4.0's qt-libs/plugins/binaries use non-qt-versioned file names/SONAMEs. I.e. qt4 and qt5-compiled binaries will conflict at runtime/installation time.
>>
>> - Qt5-built OSG is slightly incompatible with Qt4-build versions of OSG-3.4.0.
>> (Building against QT5 causes OSG to drop the osgdb_qfont.so plugin)
>>
>> - OSG-3.4.0 monolytical [monolithic?] build system treats QT4 and QT5 as mutually exclusive alternatives.
>>
>> All in all, I don't see an easy way to implement parallel installation of qt4-/qt5-build variants.
>
>
> If these issues can't be finessed, separating just osgQt into Qt 4 and 5 packages won't suffice: we'll need separate OSG builds, installation paths, and library naming. But maybe someone more familiar with Linux builds can see a simpler approach. Having both Qt 4 and 5 builds on Linux seems to have value but if that's not practical it might be time with OSG 3.6.0 to encourage Linux packagers to switch to Qt 5.

I don't think just switching to Qt5 is a solution.

I've come to the conclusion that we need separate osgQt4 and osgQt5 Libraries.

I also feel that having either in the core OSG would not be
appropriate, no other core OSG NodeKit/Libraries have external
dependencies like Qt, it has never sat alongside the rest of the OSG
as a comfortable companion. For OSG-3.6 I now think we should not
have any osgQt library included, as if we didn't when we'd encode in
the lack of flexibility for which Qt version to target for yet another
generation of OSG.

What I think is appropriate would be to first move osgQt out into it's
own separate project/repository, something we can host on our
OpenSceneGraph github account. The next step would be then to create
a dedicated osgQt4 and osgQt5 library either from within the osgQt
project or as separate projects. I would suggest that we have OSG/Qt
users step up and direct the future of osgQt/osgQt4/osgQt5. I would
suggest that this project work with a range of OSG version rather than
just the up coming OSG-3.6.

On the practicalities front we need to five write permission on the
OpenSceneGraph/osgQt project to who ever wants to lead/contribute to
it. It might be that hosting it as part of OpenSceneGraph githib
account would not serve this purpose well. I welcome suggestions on
this.

Robert.

[Andre Normann]

Hi Robert,

but there is one problem with OpenThreads when moving osgQt out of the core OSG. To get threading working with Qt5, I need the Qt version of OpenThreads. When you do not whant to have any dependence to Qt in the core OSG library, then we also need to drop the support of Qt inside OpenThreads.

Best regards,

André

[Mathieu MARACHE]

Hi,

I agree and second Andre here, one needs to have either a Qt4 or a Qt5 version of osg/ot (to be used inside Qt that is).

History repeats itself there as these issues where already there with the passage from Qt3 to Qt4. Qt proposed a Qt3Porting library that made code using the Qt3 API recompile on Qt4 seamlessly. This is not the case there.

Now this will not be an answer to Linux distribution packaging... But we have been experimenting successfully a different binary packaging option : Conan C++ Open Source Package Manager (http://conan.io). This is IMHO the most wanted feature when using C++ libraries on heterogenous configurations/platforms. 

We are able to create osg 3.2.3 libraries in those variants/mixes with all their (cascading) dependencies :

 - Windows 32bits/64bits/Release/Debug with VS10

 - Linux 64bits/Release/Debug with gcc4.8 and libstdc++

 - macOS 64bits/Release/Debug with clang7.3 libstdc++ and minosx=10.7

The reason we took this path is to be able easily to start using a new osg release in our product (with all it's dependencies) while been able to maintain older versions of our software (and possibly upgrade or patch old dependencies).

The basic concept is that you need to declare your requirements in a txt file or a python file (not so scary) and conan will pull them for you and prepare config files for your generator of choice (CMake, VS, XCode).

The getting started will go just over the basics of this : http://docs.conan.io/en/latest/getting_started.html

Now, I have been doing this on a private repository, but I would gladly propose a helping hand and bootstrap an initiative to get conan osg package appear on conan's public repository. Packages can be build with Travis-CI (and AppVeyor for windows) and uploaded to conan.io freely.

Any thoughts ?

Regards,

Mathieu

[Alberto Luaces]

Andre Normann writes:

> To get threading working with Qt5, I need the Qt version of
> OpenThreads.

Andre, does building OT with Qt5 solve the threading issues that show up
when using any mode other than SingleThreaded in OSG+Qt5?

Thanks.

--
Alberto

[Robert Osfield]

Hi Andre,

On 20 July 2016 at 07:47, Andre Normann <andre....@gmail.com> wrote:
> but there is one problem with OpenThreads when moving osgQt out of the core
> OSG. To get threading working with Qt5, I need the Qt version of
> OpenThreads. When you do not whant to have any dependence to Qt in the core
> OSG library, then we also need to drop the support of Qt inside OpenThreads.

The need for Qt to use it's own threading library is a major flaw of
Qt5 and forces you to jump through ridiculous hoops to work with it.
It's bad design from a vendor that's entirely trapped in a bubble of
controlling everything rather than provided genuine interoperability.

We'd need to move the qt thread path out of the OSG and into the
osgQt4/5 libraries. This version of OpenThreads would need to built
with a Qt specific library name if linux distributors are to use it.

This is one of the issues why Qt doesn't belong in the core OSG distribution.

[Andre Normann]

Hi Alberto,

building OT with QThread support is just one step. You also need to write your own osgQt::GraphicsWindowQt derived class to get threading working. I can not remember who posted this solution, but I think you can find in the mailing list archive. With my solution you can use multi-threading, but you can not switch between multi-threading modes. 

Regards,

André

[James Turner]

> On 21 Jul 2016, at 07:33, Andre Normann <andre....@gmail.com> wrote:
>
> building OT with QThread support is just one step. You also need to write your own osgQt::GraphicsWindowQt derived class to get threading working. I can not remember who posted this solution, but I think you can find in the mailing list archive. With my solution you can use multi-threading, but you can not switch between multi-threading modes.
>

I’ve got a GraphicsWindowQt5 (and a GraphicsWIndowQtQuick derivative) in my local tree that does that with multi-threading, and doesn’t require OpenThreads using Qt; at least on Mac it seems to work ok. What I’m working on now is an adapter to import the osg::GraphicsContext into a QOpenGLContext using the setNative API that was added in Qt 5.4; this isn’t required for the window classes but opens up another integration strategy.

Kind regards,
James

[Andre Normann]

I have now created an example which is working well. 

Here is the link: <https://github.com/anormann1974/osgviewerQt5>

It does not depend on osgQt and multi threading is working. 

Regards,

André