Hi Eric,
Have a unification script is in some ways appealing as allows one to treat
the two projects at one, but still have them mostly separate.
However, conceptually its more complicated that subsuming OpenThreads
directly into the OpenSceneGraph distribution. Management wise its also
more complicated. It may actually be more complicated that the current
status quo of having the two projects separate.
I'm keen to simplify life for myself and the community, which is why I
proposed integrating OpenThreads directly.
Robert.
On 5/2/07, E. Wing <[EMAIL PROTECTED]> wrote:
So unifying OpenSceneGraph and OpenThreads into a unified build would
be a good thing in my opinion. I understand that they are
separate/independent projects which is why I've been advocating a
'Unification' script. I think this will let us keep a leg in both
worlds.
To make the Unification script work (at least how I've written it), I
would suggest that the Subversion repo look something like this:
trunk/
CMakeLists.txt (unification script)
OpenThreads/
CMakeLists.txt (root for OpenThreads)
OpenSceneGraph/
CMakeLists.txt (root for OSG)
So if users just want OpenThreads, they can do:
svn checkout
http://www.openscenegraph.com/svn/osg/OpenThreads/trunk/OpenThreads
OpenThreads
And similarly for just OSG:
svn checkout
http://www.openscenegraph.com/svn/osg/OpenSceneGraph/trunk/OpenSceneGraph
OpenSceneGraph
If they want both, then pull
svn checkout http://www.openscenegraph.com/svn/osg/OpenSceneGraph/trunkOSG_OT
If you want to build each project separately, you do exactly as we do
now; point CMake to each project's root CMakeLists.txt.
But if you want to build the two together, then point CMake to the
Unification script that resides above both of them.
The downside to the unification script is that there are some rough
spots where options may be redundant or clobber each other. I was
fairly careful about prefixing OPENTHREADS_ or OSG_ prefixes to all
our variables to minimize the clobbering case, but setting common
CMake variables may still lead to clobbering issues. But I think it
will work well enough where most people won't notice or care.
I would be against embedding/maintaining other 3rd party dependencies
like libjpeg, libpng, etc though. That's more work and more complexity
than I think we should handle and really outside the scope of OSG.
That's something for those communities to handle in my opinion.
-Eric
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
