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 On Wed, Jul 20, 2016 at 8:47 AM Andre Normann <andre.norm...@gmail.com> wrote: > 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é > > > 2016-07-19 16:08 GMT+02:00 Robert Osfield <robert.osfi...@gmail.com>: > >> Hi Stuart, >> >> On 18 July 2016 at 18:24, Stuart Mentzer <osgfo...@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. >> _______________________________________________ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
