On Wed, Jan 20, 2010 at 2:37 AM, Gerrit Voß <vo...@vossg.org> wrote:
>
> Hi,
>
> On Fri, 2010-01-15 at 21:40 +0800, Gerrit Voß wrote:
> > Hi,
> >
> > >
> > > Ok, jumping into the technical discussion, if possible (and
> > > hopefully
> > > without to much work on your side) I would like to propose a
> > > slightly
> > > different inclusion process from what you started in the sf
> > > git repo.
> > > Ideally we could use this as the general blue print, and
> > > derive some
> > > documentation of the process from it.
> > >
> > > The general process I would like to use, given that the
> > > current
> > > cmake system makes it possible to include externally kept libs
> > > into the OpenSG build quite easily (e.g. something like
> > > http://github.com/vossg/OSGAddOnsGV) is to stage things first
> > > this way.
> > >
> > > Ok, It sounds like you would like me to move the lib porting into
> > > the
> > > http://github.com/vossg/OSGAddOnsGV repo. I could put a remote branch
> > > of this somewhere, or could/should I get write access to this one?
> >
> > not necessarily, OSGAddOnsGV was just an example of an external set of
> > libs that can be build together with OpenSG or on top of an OpenSG
> > installation. So you can keep it at your preferred location.
> >
> > Actually I would create a separate repository on github. I probably
> > do it so you can see how this structure looks like. I will also
> > use a clone of DevMaster to stage/store your core OpenSG changes
> > that can not be externalized.
> >
> > >
> > > One of the advantages is separating out the core changes.
> > >
> > > Changes to OpenSG itself could be ideally handled over github
> > > and pulled independent of the rest.
> > >
> > > Also, once we have it running in this staging setup it is a
> > > lot
> > > easier to work with it and understand the implications. Moving
> > > from the staging area into the main OpenSG tree is usually
> > > not that difficult, for things that go into contrib it is
> > > straight forward. It also should be able to handle external
> > > dependencies, if not I want to fix this anyway.
> > >
> > > As a starter if you give me probably the weekend I could
> > > look into what is already inside the sf git and try to
> > > come up with a initial external setup suggestion.
> > >
> > > Should I wait for further information on this, or could I continue to
> > > work on some of the porting on the remote branch I am using now?
> >
> > you should be able to work on the porting while I get a better
> > idea and do the basic prep work. I would also like to take a
> > little time to document the process.
> >
> > > If it would not be too difficult to move over to your inclusion
> > > process, then I would like to continue the porting on my remote
> > > branch.
> >
> > no it shouldn't. The good thing with being 14 hours ahead of you
> > is that for the one point where things should move to the different
> > structure it can be done overnight for you (if you want me to do
> > it).
> >
>
> ok, I got the basic setup done, mainly splitting things into what
> absolutely must be inside Source/System, Source/Base, ... and
> what can stay outside. I started working on the build system, so
> far the main OpenSG things compile with the changes. Now comes
> the external stuff.
>
> Two questions ;)
>
> Could you give me a rough idea what is expected to build right now.
>
For the toolbox-migration branch of the git repository on the OpenSGToolbox
sourceforge site, all of the stuff that was moved into Base and System
should build(This includes most of the capabilities of Toolbox, Input, and
Animation libraries), The Sound Contrib library, the Physics Contrib
library. I have been working primarily on OS X, so I have not tested the
linux or windows builds, this may cause a problem with the build of the
Win32 and X WindowEventProducers.
>
> And is it ok with you if I push what I did to github so you can
> see it.
>
Absolutely, in fact I may prefer to work off of it with you, if that is also
ok.
Cheers,
David Kabala
>
> kind regards
> gerrit
>
>
>
>
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for
> Conference
> attendees to learn about information security's most important issues
> through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> Opensg-users mailing list
> Opensg-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/opensg-users
>
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
