gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject Re: Traditional vs. Gumpy Debug Usability
Date Mon, 15 Mar 2004 16:30:49 GMT
On Mon, 15 Mar 2004, Stefano Mazzocchi <stefano@apache.org> 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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Mime
View raw message