Don's recent additions to Producer (i.e. ProducerOSG) have introduced a circular dependency. Producer is now dependent on OSG, OSG on Producer. Not a pretty sight if you are coming to project for the first time and need to know which one to install and compile first. We'll need to resolve this issue before the next release of the OSG. I don't know what Don has in mind w.r.t this problem, whether its just a short term thing and ProducerOSG will be moved later, or something he expects the OpenSceneGraph to reshuffle to accommodate.
Four solutions spring to mind:
1) Mixed build order 1
a) Build OpenThreads
b) Build Producer without ProducerOSG
c) Build OpenSceneGraph complte
d) Build ProducerOSG
2) Mixed build order 2
a) Build OpenThreads
b) Build OpenSceneGraph without osgProducer or osgProducer based examples
c) Build Producer complete
d) Build OpenSceneGraph osgProducer and osgProducer based examples
3) ProducerOSG to be kept seperate from Producer
a) Build OpenThreads
b) Build Producer
c) Build OpenSceneGraph
d) Build ProducerOSG
4) osgProducer and osgProducer based examples to be split off from core OpenSceneGraph
a) Build OpenThreads
b) Build OpenSceneGraph
c) Build Producer
d) Build osgProducer and associated examples
5) Fork Producer and merge it with osgProducer but keep seperate from OSG
a) Build OpenThreads
b) Build OpenSceneGraph
c) Build osgProducer and associated examples
6) Fork Producer and merge it with osgProducer but maintain it as part of the OSG
a) Build OpenThreads
b) Build OpenSceneGraph
7) Move osgProducer into Producer and maintain it as part of the Producer
a) Build OpenThreads
b) Build OpenSceneGraph
c) Build Producer
Now 1 and 2 is the situation right now, but it isn't viable so we can discount them for anything other than a short term CVS, experts only thing.
Option 3 is down to what Don want to do with ProducerOSG and Producer.
Option 4 is possible, this would cause a bit of hassle for me in the short term but viable. It is even more projects for end users to worry about though.
Option 5 is possible, this would mean a forked Producer merged with osgProducer would happen without Don's support, we'll have to maintain it ourselves. One could sort out lots of duplication in classes though, so it would probably be a nicer API to use that the current seperated osgProducer/Producer.
Option 6 is really just like Option 5, with the same up and downsides. A bit more convenient for end users as it'll cut down on the dependencies one has to worry about. It might be even that Option 6 could come first, then later once osgViewer has grown up a bit more in its capabilities, osgProducer moves out on its own (Option 5.)
Option 7 is technically possible, but Don has expressed displeasure at osgProducer so I think it unlikely that he'll want to sully Producer with it or maintain it thereafter.
For all these different options I see osgViewer still having distinct features right now that warrent its existance, and long terms I feel this type of tight integration is needed. However, I am very concerned about supporting existing osgProducer users, and am certainly not about to make any major changes to osgProducer or to drop support for it. While neither Don or I don't consider the long term future not be centered osgProducer, but its very much an important part of present OSG usage that needs to be maintained for backwards compatibility. I don't know if Don shares this concern about maintaining osgProducer, so big changes to Producer are a concern with this respect.
So community, what are your thoughts?
Robert.
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
