Gerrit Voss wrote: > Hi, > > On Tue, 2007-02-13 at 09:53 -0600, Allen Bierbaum wrote: > >> Dirk Reiners wrote: >> >>> Hi Gerrit, >>> >>> Gerrit Voss wrote: >>> >>> >>>> Hi, >>>> >>>> I'm at a stage where I start to change scons and scons-addons frequently >>>> so I would like to switch to local copies inside the OpenSG repository. >>>> >>>> >>> What do you need to change inside scons? Switching to scons-local is not a >>> bad >>> idea in general, but changing stuff in there sounds a little troublesome. >>> >>> >> I agree, this sounds a bit worrisome to me. If OpenSG ends up with >> customized versions of SCons and scons-addons, then we will end up with >> completely custom build systems that have to be supported. >> > > adding new tool chains (intel compiler, cuda, ...) is just easier inside > scons-cons and scons-addons than trying to squeeze them into SConstruct > or SConscript. I did not find a way to add new tools to scons-addons (or > somewhere else) so that you can use them with a custom tool list when > creating the build environment. Similar I did not want to replicate the > environment builder or variant-helper from scons-addons which you need > to change as you add new tool chains. But maybe I'm just missing > something. > > I think you can extend the default scons toolchain, but I would need to check on that. If not, it should be possible to write a little utility library for OpenSG that could modify an SCons environment and extend it with whatever custom tools we need. This could even be made a part of scons-addons if you think the tools would be useful for other people.
> 'Completely custom' is probably not what we are going to end up with. > > It's more like the basic versions plus some small tweaks. I don't see > a problem in keeping track of the major changes of either scons or > scons-addons as vendor branches (that's how I run them locally for > now anyway). > Both systems are pretty extensible (python is general is very good at this), so I guess what I am missing is how the small tweaks need complete copies of the tools instead of just injecting the additional capabilities in at runtime. For example having the first thing the SConstruct file does is load some OpenSG utility modules and then use them to inject tools and extensions into the SCons defaults. I think this is how other projects are doing it as there has been some discussion on the SCons list about this. If not, I am sure someone on their mailing list could suggest a good way to do it. As far as scons-addons, I am willing to give you commit access to that project so we can just keep making it better. If there is a tweak that is needed, then it is probably either a bug or a limitation that we want to fix anyway right. :) > I don't have a problem with supporting it as I'm going to switch > everything we do to scons + scons-addons. That's were some of the > changes are initially coming from. But in the end they will be needed > for OpenSG. And at the same time they give a 'users perspective' on > what I would expect if I start using OpenSG and go on from their to > build my own projects. > > For example some of the stuff in SConstruct (roughly up to line 500) > should be in scons-addons (from an OpenSG only perspective). So it is > reusable for people who want to write their own applications. > I agree there is a lot of utility code in there. I am not sure if it all makes sense in scons-addons (some of it does), but the OpenSG part IMHO should actually be put into some utility libraries in OpenSG2/Tools/scons-build where the LibraryUtils module currently is. That would allow this code to be hidden away and reused as simple python modules. That is the nice thing about having a python-based build, we can modularize and reuse parts of the build just like we would with standard python code. :) > Currently you have to copy stuff over to your own project if it contains > fcd files or want to use the build info stuff from OpenSG. > Agreed, and that is a pain. We should take all the reusable pieces and put them somewhere central for reuse. IMHO this should be local to OpenSG unless it is related to something more then just OpenSG in which case it could go to scons-addons. > >> Isn't it possible to submit the modifications you need back to the >> associated projects? >> > > as they are finished and up to the point where they make sense yes. > > But the time in between (until they are accepted upstream, if they are) > is a problem. I don't have a good idea how to do this without having a > local copy inside OpenSG. > In the case of SCons, you could use the standard python methods of overriding and injecting methods, classes, etc. In the case of scons-addons I can just give you commit access. :) -Allen ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Opensg-core mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-core
