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.
Ahhhhh, I get it.
FYI, Forrest is almost never used from the command line during debugging, but it's used dynamic bound to a particular port.
Basically, it doesn't have to regenerate everything but only the pages that you ask for when you are browsing.
Also, keep in mind that on the gump machine we could keep running forrest dynamic, we have no need to pregenerate the website.
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.
I understand, but as long as that information on what is missing in gumpy doesn't come across, it would be hard to polish the edges.
I think we identified a problem in the slow latency introduced by the generation of documentation by forrest in Gumpy that wasn't there for Traditional gump.
and I think this can be solved by running a dynamic forrest instead of a command-line driven one.
thoughts?
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
