Hi JS, On Fri, Oct 8, 2010 at 1:55 PM, Jean-Sébastien Guay <[email protected]> wrote: > One concern I've had since we started these discussions on osg/glu/** is > that you stated in your first e-mail on osg-users ("[osg-users] GLU > integration") that you kept the directory/file structure identical to Mesa > so that you could easily merge in any upstream changes they make in the > future. All the changes you make to the files themselves go against that > goal, don't they?
Yes, the more changes I make the more difficult it will be to merge fixes. Right now I have made changes that solve problems that we want to solve on the OSG side, or fix things because we are compiling them as C++ rather than C. > I don't know if it's at all possible, but one approach you could have used > would have been to have a separate "mesa compatibility" header that you'd > include at the top of these files, and in which you'd have #defines and > declarations that would make the code work as-is. That way when merging a > future version of the same code from Mesa you'd see that the only change to > the actual files is the header at the top, all other differences would be > changes Mesa made so would be merged in as-is. > > Just a thought, as I said it might not even be possible and it increases > complexity (probably a lot) but at least it preserves the goal of being able > to update the code later. If that's not an important goal after all (or a > less important goal than code clarity, which is probably the case) then just > ignore this idea... :-) My plan has to be to aim at strive it easy to map between the Mesa/sgi source code and the OSG version, but have already encountered a number of issues that aren't possible to resolve without breaking a direct correspondence. I'm OK with the code base diverging if we have a good reason for it diverge, but not just changing things because we'd prefer a different code style. In terms of headers, I've tried to keep the majority of #define, typedef and function entry points the same as the glu versions, but have put them in the osg namespace to avoid collisions. Now we have started diverging from 100% compatibility we could actually ask whether we should drop the pretence that these are glu functions. Another path might be to make the GLU headers private to the implementation of the OSG and not part of the public headers that end users use. This would force users to go through OSG classes to access that functionality, but this is pretty well what already happens in most cases. For now I'm happy to just get the GLU based code compiling and working across all platforms and GL targets. GLES and GL3/GL4 are the next big hurdles to address. Once things have bedded down we can return to the issue of how much we strive to retain compatibility and whether we want a public interface to the GLU functions. Robert. _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
