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

[Robert Osfield]

Hi Stuart,

On 18 July 2016 at 18:24, Stuart Mentzer <osgforum at 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.