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. And is it ok with you if I push what I did to github so you can see it. 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
