On Mon, 15 Mar 2004, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote: > Stefan Bodewig wrote: > >> Right now "traditional" beats Gumpy hands down when it comes to >> debugging a build problem. > > I'm kinda worried by this comment. Can you elaborate more?
It is related to my comments about getting Gumpy running on my machine. The workflow for testing Niclas changes has been # regenerate workspace (takes about a minute) cd ~/gump cvs up -dP gen.sh # try whether it works using the freshly created shell scripts cd /javastuff/gump # update avalon-excalibur working copy ./update.sh avalon-excalibur # make sure our scratch area is clean rm -rf avalon-excalibur/event cp -r cvs/avalon-excalibur/event avalon-excalibur # try to build ./build.sh excalibur-event-api jars this all took less than three minutes. After Niclas added a build file, I only had to redo the last steps starting with update.sh, less than two minutes to complete. Next: # try to build ./build.sh excalibur-event-api-impl jars fails because jar name is wrong. ten seconds to get the failure and a a few more to spot the reason (as it was expected, it would have taken much longer if it had been a different reason). Change excalibur descriptor, rerun gen.sh and rerun only the excalibur-impl build. Three minutes, things worked. So the whole test/patch/retest cycle took less than ten minutes. If I had done the same using integrate.py the Forrest documentation step alone would have taken three times as long. The one for the very first build, that is. It would have synced away the ant module and rebuild Ant as well as all other things excalibur-event depends upon during that process as well. All in all it would have taken a lot longer. I'm not complaining. I know that Adam has been working mostly on intgrate.py and that all the bits are there to create Python equivalents of what I need to quickly test a descriptor change - it's just not there yet. As long as it isn't - and as long as I cannot find time to dive in deep enough to lend a hand - "traditional" will be my tool of choice when I need to debug a single build. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
