Hi Art, Paul,
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.
Just to chime in with another data point, we generally want to keep our
OSG graphics integration compatible with at least two generations of OSG
(currently 2.6.x and 2.8.x), but in general we're compatible across the
whole spectrum from 2.2 on (some features are not usable on such old
versions but they're disabled by compile-time checks). We might be
compatible with 2.0 as well, we just never checked (we moved from 1.2 to
2.2 directly).
We use the OSG_VERSION_GREATER_OR_EQUAL and OSG_VERSION_LESS_THAN macros
in some places, mostly where we derived a class to work around a bug we
found in a given version of OSG, and also submitted the fix to the base
osg:: class in parallel, so the next stable version contains the fix and
doesn't need the derived class anymore. But they're used only
sporadically, and the code is still very manageable and clear.
J-S
--
______________________________________________________
Jean-Sebastien Guay jean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
