Re: [osg-users] osgQt versioning problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/12/2015 10:02 PM, Robert Osfield wrote: Perhaps one would just need to avoid using the whole MOC stuff and linking directly the callbacks in normal C++. That isn't really reasonably possible without going into undocumented/internal API territory. MOC doesn't really pose problems in general, as long as you don't try to be too clever with your headers. The idea of moving the implementation to headers is, honestly, a hack to work around another problem, so it is hard to blame MOC for not supporting/breaking on something like that. For example, Unreal Engine doesn't even use a custom preprocessor and use C++11 for the part. And good luck trying something like that there - their C# build tool acts as a code generator too and will blow up spilling its guts all over with much less prodding than MOC ever did. If you want to actually solve the problem, then the cleanest solution would be to split osgQt into a subproject with its own CMake build. That would avoid having Qt CMake variables clobbered between Qt versions . Then run the osgQt build as many times as many Qt versions were checked/activated by the user in the master/top level build, generating libraries with different names - e.g. osgQt4, osgQt5, etc. Those can be installed side-by-side no problem. J. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iD8DBQFVfBO6n11XseNj94gRAlG/AKCXtqPEKbjqmwm08ZBXHnrRu1DPkQCgpmqI QcJ6mbbnGC2V5qSUyS/ykWA= =KbOs -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt versioning problem
On Fri, Jun 12, 2015 at 1:00 AM, Jannik Heller scr...@baseoftrash.de wrote: Hi Jan, The only way you could have problems is if you rely on the OSG libraries shipped by the distro, where you don't have control over how it was compiled. That is precisely what's going to happen. My application is likely to become available in distro repositories (FWIW, an older version of my application that isn't using the OSG *is* already in distro repositories). Packaging guidelines typically require a package to use the established library stack. A package isn't likely to get accepted if it ships its own forks of already packaged software. That would be a maintenance and security nightmare. Then it cannot be a problem, because all distros recompile the applications they package for their repositories using their libraries. You can specify in the spec file (if you are building for RPM-based distro) or the manifest for .dpkg (for Debian/Ubuntu/...) which library version your application needs. Then the package will not build for the repository maintainer until the requirements are met. The only exception are binary-only, proprietary software packages - but there you are on your own and shipping everything needed is your problem. Sounds easy in principle, but will cause a waterfall of problems for package repositories. I don't see how - if you set up your package requirements properly, then there is no way the repository maintainer could build your package requiring one version of Qt and build OSG using another one. - Not all application developers are willing or able to upgrade to Qt5 yet. - *if* there is a mismatch, we just get a crash, instead of the mismatch being detected at the build system stage. The packager or tester is left to dig into the crash to find out what's wrong. There is no way for the application to detect what version of Qt the osgQt was built with, so the application can't provide a sensible error message either. Ultimately, the developer will be left to deal with lots of support requests by frustrated users. - If one package requires osgQt5, but a different one requires osgQt4, we get a conflict. The user wouldn't be able to install those two packages at the same time. Well, there isn't really a way around that - you must have two versions of OSG installed side by side for this to work. That's the responsibility of the distro packager, IMHO, not yours. If they build the packages inconsistently, despite your specified requirements, well, things won't work, but only they are to blame in such case. OSG is no way special there - this is a common issue with software requiring e.g. specific version of Python, wxWindows toolkit, KDE/Gnome ... In addition, if you are trying to distribute a binary-only package I don't. I just distribute source-code and let others worry about the rest ;) OK. I would say that the only thing you could do is to document this requirement. It is the packagers' job to deal with this. My suggestion is: - Provide separate libosgQt4/5 libraries. - Provide a libosgQt library that points to the default, either 4 or 5, for backwards compatibility. - Add an OSGQT_DESIRED_QT_VERSION switch for the FindosgQt.cmake script, allowing applications to opt for a specific version. You just have to build OSG twice using each version of Qt in turn. OSG respects the DESIRED_QT_VERSION already. cmake -DDESIRED_QT_VERSION=5 - use Qt 5.x cmake -DDESIRED_QT_VERSION=4 - use the Qt 4.x series Regards, J. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt versioning problem
Hi Jannik, On 12 June 2015 at 00:00, Jannik Heller scr...@baseoftrash.de wrote: Still, I'm convinced there's a bigger issue here. I'd be curious what Robert's thoughts are. Issue like dependencies on 3rd party libraries that keep changing versions/compatibility in major ways is painful for everyone. I miss the day when the OSG had very few external dependencies. For this particular issue I see a couple possible approaches: 1) Maintain two separate osgQt libraries, an osgQt4 and an osgQt5 2) Move the implementation in src/osgQt into the headers in include osgQt and have no osgQt library 3) User provides their own Qt integration. Thoughts? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt versioning problem
Hi, You just have to build OSG twice using each version of Qt in turn. OSG respects the DESIRED_QT_VERSION already. cmake -DDESIRED_QT_VERSION=5 - use Qt 5.x cmake -DDESIRED_QT_VERSION=4 - use the Qt 4.x series Yes, but then you won't be able to install those two OSG versions at the same time. Unless you renamed libraries or used a completely separate prefix for each OSG build, but there isn't an established pattern to do so, so what we'd end up with is each distribution inventing its own ways to cope with the versioning problem. That is what should be avoided at all cost. You can specify in the spec file (if you are building for RPM-based distro) or the manifest for .dpkg (for Debian/Ubuntu/...) which library version your application needs. Then the package will not build for the repository maintainer until the requirements are met. I don't see how - if you set up your package requirements properly, then there is no way the repository maintainer could build your package requiring one version of Qt and build OSG using another one. Speaking for some popular distro's that I've seen, there is a way to request a version of the OSG, but no way to request a Qt version of osgQt. No one bothered to add separate versioning for it, probably because the OSG itself doesn't provide one either so doesn't set a precedent on how it should be done. See my earlier comment w.r.t each distribution being forced to invent their own solutions. Yes, it can work, if you jump through some hoops and are careful in what you do. My point is: it *should* work out of the box. A framework is supposed to make the developer's job easier, not harder, after all. In my experience with packaged repositories, whatever can go wrong, *will* go wrong eventually. Thus having proper safeguards in place can safe you a lot of time. 1) Maintain two separate osgQt libraries, an osgQt4 and an osgQt5 That sounds good. It wouldn't have to be a separately maintained source tree, just building the same tree twice with different build parameters. Cheers, Jannik -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=64071#64071 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt versioning problem
On Fri, Jun 12, 2015 at 2:51 PM, Jannik Heller scr...@baseoftrash.de wrote: Hi, You just have to build OSG twice using each version of Qt in turn. OSG respects the DESIRED_QT_VERSION already. cmake -DDESIRED_QT_VERSION=5 - use Qt 5.x cmake -DDESIRED_QT_VERSION=4 - use the Qt 4.x series Yes, but then you won't be able to install those two OSG versions at the same time. Unless you renamed libraries or used a completely separate prefix for each OSG build, but there isn't an established pattern to do so, so what we'd end up with is each distribution inventing its own ways to cope with the versioning problem. That is what should be avoided at all cost. Yes, correct. However, there are few applications that *need* OSG that are commonly packaged by Linux distros and that don't ship their own OSG. So you build the package against whatever OSG/Qt combo is on the machine. If someone then force installs the wrong version of Qt, breaking dependencies, that's not really something you can do much about. Speaking for some popular distro's that I've seen, there is a way to request a version of the OSG, but no way to request a Qt version of osgQt. No one bothered to add separate versioning for it, probably because the OSG itself doesn't provide one either so doesn't set a precedent on how it should be done. See my earlier comment w.r.t each distribution being forced to invent their own solutions. OSG does provide an option to choose the Qt version already. This problem is hardly unique and is commonly encountered - have a look at e.g. apps using OpenCV, wxWindows, or Gnome libraries. Typically these additional requirements are documented in the README/INSTALL file, so the packagers (or whoever is compiling the application) should pay attention to it. Again, that not something you, as the app developer, should be dealing with. Yes, it can work, if you jump through some hoops and are careful in what you do. My point is: it *should* work out of the box. A framework is supposed to make the developer's job easier, not harder, after all. In my experience with packaged repositories, whatever can go wrong, *will* go wrong eventually. Thus having proper safeguards in place can safe you a lot of time. Agreed. However, there isn't all that much that OSG can (or even should) do here. What are you going to do if the distro packagers decide to build OSG with no Qt support at all to reduce dependencies (completely legitimate thing from a packager's point of view)? It is an optional component, finally. 1) Maintain two separate osgQt libraries, an osgQt4 and an osgQt5 That sounds good. It wouldn't have to be a separately maintained source tree, just building the same tree twice with different build parameters. That could be an option, but probably you won't be able to build it from the same build folder by re-running cmake with different options - the CMake Qt variables conflict (not OSG specific, that's a CMake thing). So you would need to build in separate folders (or wipe the CMakeCache.txt, but that is equivalent - causes a full rebuild). J. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt versioning problem
Hi Robert, that's certainly an option, and it seems like the option that would place the least burden on developers. I like the idea. Counting the lines of code in osgQt we have just under 2000 lines in implementation files, having that much code in headers shouldn't be too much of a problem. I don't know how feasible it is, it'd require us to automatically select between Qt4 and Qt4 based in someway. Perhaps an osgQT/QT4 and osgQT/QT5 headers could include all the appropriate parts required, and then have 3rd party apps include which one they want, and have these set defines to select the different paths. Not even that is necessary, I think. The osgQt headers already have #if QT_VERSION_CHECK(...) macros to select the appropriate code. Users would be able to #include osgQt/... and automatically get the correct code for the Qt version that their application is using. It's a bit more work though to move that much code around, so for now I'm submitting the osgQt/Version fix. We can undo it later if the better fix comes around. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=64078#64078 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt versioning problem
On 12 June 2015 at 20:58, Jannik Heller scr...@baseoftrash.de wrote: On second thought, I'm not sure how this solution would interact with the MOC (QT meta object compiler). osgQt::QGraphicsViewAdapter is a Q_OBJECT, meaning the MOC needs to run on it and produce an object file. If we move all code to the headers, then it would fall on the users responsibility to make sure they run the MOC on osg-headers. That's not too optimal. Bits of Qt are just crap with clever solutions like MOC that often just end up introducing their own problems. Perhaps one would just need to avoid using the whole MOC stuff and linking directly the callbacks in normal C++. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt versioning problem
On second thought, I'm not sure how this solution would interact with the MOC (QT meta object compiler). osgQt::QGraphicsViewAdapter is a Q_OBJECT, meaning the MOC needs to run on it and produce an object file. If we move all code to the headers, then it would fall on the users responsibility to make sure they run the MOC on osg-headers. That's not too optimal. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=64079#64079 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt versioning problem
Hi Jannik, On 12 June 2015 at 18:24, Jannik Heller scr...@baseoftrash.de wrote: as a first step to rectify the problem I have introduced a version check within osgQt (include/osgQt/Version) to store the Qt version that osgQt has been compiled against. If there is a version mismatch, the build process will abort with an #error rather than crashing at runtime later on. Will post to osg-submissions in a second. Sounds like a reasonable improvement. Have you looked at the option of moving the implementation to the headers? I don't know how feasible it is, it'd require us to automatically select between Qt4 and Qt4 based in someway. Perhaps an osgQT/QT4 and osgQT/QT5 headers could include all the appropriate parts required, and then have 3rd party apps include which one they want, and have these set defines to select the different paths. I'm just throwing out ideas here - I have no clue what might actually work well. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt versioning problem
Hi, as a first step to rectify the problem I have introduced a version check within osgQt (include/osgQt/Version) to store the Qt version that osgQt has been compiled against. If there is a version mismatch, the build process will abort with an #error rather than crashing at runtime later on. Will post to osg-submissions in a second. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=64076#64076 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt versioning problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/11/2015 10:19 PM, Jannik Heller wrote: Hi, Recently I have had my application tested on a wide range of linux distributions. Some users are running into a problem with Qt version mismatch. My application gets built with Qt4, but osgQt might be built with Qt4 or Qt5. If you load Qt4 and Qt5 libraries in the same executable, a crash ensues. This means you have built your application incorrectly. It is normally not possible to start an application built with Qt4 using Qt5 libraries and vice versa - the APIs and ABIs are not compatible, the library version numbers are different and the application will not start . This forces users to rebuild the OSG with a particular version of Qt, just to run a certain application, which is bad. It is unfortunately inevitable, because Qt4 and Qt5 are not compatible. There were huge API changes, some libraries were removed and many more added between Qt4 and 5. For a proper solution, the OSG could provide libosgQt4 and libosgQt5 libraries, along with find scripts that allow the application to request a particular osgQt version to be used. What do you think about the idea? I don't think that is necessary - you need to ensure in your application that it is built against the correct version of Qt which is the *same as the version you use for osgQt*. Then you ship both OSG libraries and your application. The CMake scripts for Qt and OSG allow specifying the Qt version already. And most Linux distributions ship both the older Qt4 and the new Qt5 series, so if you build for one of them, it should work. The only way you could have problems is if you rely on the OSG libraries shipped by the distro, where you don't have control over how it was compiled. However, that is a terrible idea, because that OSG tends to be outdated and many distributions don't ship OSG at all. In addition, if you are trying to distribute a binary-only package, you are going to have major problems with library version and C++ ABI incompatibilities between distributions. Qt will be the least of your problems. You should always ship your shared libraries with the application or recompile/package the software for the particular distribution. J. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iD8DBQFVefgYn11XseNj94gRAjQ+AKCk66wnwYe6LPfM35sJCxMsCwNCyACfcjCU BQs5Q4TgtHM5+vB8zQdI054= =hWe4 -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt versioning problem
Hi Jan, The only way you could have problems is if you rely on the OSG libraries shipped by the distro, where you don't have control over how it was compiled. That is precisely what's going to happen. My application is likely to become available in distro repositories (FWIW, an older version of my application that isn't using the OSG *is* already in distro repositories). Packaging guidelines typically require a package to use the established library stack. A package isn't likely to get accepted if it ships its own forks of already packaged software. That would be a maintenance and security nightmare. I don't think that is necessary - you need to ensure in your application that it is built against the correct version of Qt which is the *same as the version you use for osgQt*. Sounds easy in principle, but will cause a waterfall of problems for package repositories. - Not all application developers are willing or able to upgrade to Qt5 yet. - *if* there is a mismatch, we just get a crash, instead of the mismatch being detected at the build system stage. The packager or tester is left to dig into the crash to find out what's wrong. There is no way for the application to detect what version of Qt the osgQt was built with, so the application can't provide a sensible error message either. Ultimately, the developer will be left to deal with lots of support requests by frustrated users. - If one package requires osgQt5, but a different one requires osgQt4, we get a conflict. The user wouldn't be able to install those two packages at the same time. Yes, these aren't problems if you ship your application with static libs, but not everyone can or wants to ship software in this way. In addition, if you are trying to distribute a binary-only package I don't. I just distribute source-code and let others worry about the rest ;) My suggestion is: - Provide separate libosgQt4/5 libraries. - Provide a libosgQt library that points to the default, either 4 or 5, for backwards compatibility. - Add an OSGQT_DESIRED_QT_VERSION switch for the FindosgQt.cmake script, allowing applications to opt for a specific version. For now, I'm going with the workaround of upgrading my application to Qt5. Still, I'm convinced there's a bigger issue here. I'd be curious what Robert's thoughts are. Thanks, Jannik[/quote] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=64064#64064 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
