Art Tevs wrote:
Ok, then it explains why it does not compile. Yes, svn trunk of osgPPU tracks the svn trunk of OSG.
Hmm, I wonder how to handle different osg branches in future. I mean if again
something like this happens, then I had either to create additional branch in
osgPPU repository to track with the according osg branch (which I didn't really
like) or to detect the version and write preprocessor or cmake workarounds for
that (which is also not a good solution).
I'm not sure what new problem OSG 2.8.3 has created for osgPPU that didn't
already exist with the OSG 2.8.2 release. Can you explain the problem?
The same version of osgPPU that works with 2.8.2 should also work with 2.8.3.
osgPPU trunk is broke with OSG 2.8.3, but it was also broke with OSG 2.8.2.
Suppose the 2.8.3 release never happened, and Allen was trying to build svn
trunk of osgPPU with the OSG 2.8.2 release. That would also not work, right?
What would you tell him to do in that case? The same answer should apply to 2.8.3.
For this release I will go for a preprocessor solution, I think.
My external projects osgWorks and osgBullet are compatible with OSG 2.6.1 and
later. osgWorks contains version-specific code in only two places (to handle the
OSG API changes in Registry and Traits that occurred in OSG 2.6.0 and 2.8.0
respectively). And osgBullet contains no version-specific code at all; all
osgBullet code is 100% compatible with OSG 2.6.1 and later.
So, my use of the C preprocessor for OSG compatibility is very infrequent and is
not a problem in itself. However, testing on different versions can be a burden
to external project managers, and that's a decision you have to make.
--
-Paul Martz Skew Matrix Software
http://www.skew-matrix.com/
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
