[osg-users] osgQt versioning problem

[Jan Ciger]

On Fri, Jun 12, 2015 at 2:51 PM, Jannik Heller <scrawl at 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.