Handling OSG's incompatible API changes

[Paul Martz]

Hi all -- The osg::Geometry class appears to be undergoing a series of modifications that break existing code. I'd like to start a discussion on what people think might be the best way to support both OSG trunk and also v2.8.5. I'm not familiar with the changes in OSG trunk, so I'll rely on the expertise of others here.

One option would be to modify osgWorks with a liberal sprinkling of CPP guards around affected code. This was done, for example, in r528.

Since r528, yet more incompatible changes have been made in OSG, as noted in this osgWorks issue: https://code.google.com/p/osgworks/issues/detail?id=41. This makes me wonder if continued liberal use of CPP guards is the correct approach?

So, for the second option, I'd propose a more wholesale use of CPP: For a given affected file, we could have:

#ifdef OSGWORKS_OSG_VERSION < 30108 )

    place original file contents here

#else

    place new version of file here

#endif

This would give us uncompromised v2.8.5 compatibility, and the new code could probably be lifted directly from OSG trunk in the case of things like TangentSpaceGeneratorDouble and MeshOptimizers. The new code could also be maintained independently of the existing code.

A third option would be to branch osgWorks: a v2.8.5 branch, and an OSG main trunk compatibility branch. This makes sense to me, if the changes to osg::Geometry are as drastic as I understand them to be. This would also be a good safeguard against any possible future incompatible changes to OSG.

Does anyone have other ideas or suggestions on how to proceed? Thanks.

--
Paul Martz
Skew Matrix Software LLC

[Doug McCorkle]

Paul,

I think there is a 4th option. We could create two separate *.in files for the geometry files and at compile time create the neccesary cpp file that would be compiled. This option would reduce the use of CPP macros. We can determine this through a compile test of the geometry code with the user specified OSG build during cmake generation. I would be glad to implement this option. Personally I would like to avoid large swaths of code being ifdef'ed away.

Doug

> --
> You received this message because you are subscribed to the Google Groups "osgworks-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to osgworks-user...@googlegroups.com.
> To post to this group, send email to osgwork...@googlegroups.com.
> Visit this group at http://groups.google.com/group/osgworks-users.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Paul Martz]

Personally, I was kind of leaning towards a branch (my option 3). I've been intending to tag a 2.01.00 osgWorks release for the past month or so. I could make a branch and tag the release. Any future changes for v2.8.5 would go there (I don't expect many / any), and trunk would be open for OSG 3.x support.

But you guys go ahead and decide what you want. My hands are currently full with non-OSG dev work.

[Doug McCorkle]

Everything will stay the same except for new features….

I am good with a branch only if we identify who will be responsible for merging changes.

Doug

[Paul Martz]

Another possible solution is to remove the offending files from the build if the OSG version is > 3.1.8. Things like the MeshOptimizers are a backport for 2.8.5 anyway, and are already present in OSG trunk.

On the topic of a branch, I'm not sure that a branch will create a lot of maintenance issues. There will be few changes on the 2.8.5-support branch. Maybe support for new compilers, that sort of thing.