[osg-users] osgQt versioning problem

Jan Ciger jan.ciger at gmail.com
Sat Jun 13 04:27:54 PDT 2015

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.

Version: GnuPG v2.0.22 (GNU/Linux)


More information about the osg-users mailing list