"> You may want to look at Scons (www.scons.org):

And so I did.

I need to look at it more though.
I covers all the issues I have mentioned. At least in its statet goals.
If it delivers what it claims in what I have already read, I think this is a
very good system.
There is one issue that concerns me slightly:
Can SCons correctly ensure that a build source mentioned multiple times will
only be targeted once.
It does have a digital signature, but I'm not sure what happens if the same
file happens to be represented in two build objects instead of one. This is
a point that Jam goes to great lengths to handle. But even if SCons doesn't
do this as well, it still looks great.
Among the features are custom scanners for dependencies.

I think I'm going to try it out to see if I can use it as a build system,
although this would require me to get at least slightly aquainted with
Python...

I have to look more at the system to say anymore specific - so I shall be
general.
I previously mentioned that the greatest work in creating a better Ant
system would be in the design.
It appears that SCons has done this design and done it right. Hence if a
build system is to be developed in Ruby, I think that it might well stay
close to SCons. Scons claims it is extensible such that you could implement
Make compatibility if you'd care to do it. You could probably put Ant
compatibility into it as well. That would mean no loss of generality by
staing with SCons.
SCons has a job system that by description sounds much like Torrent. It also
has or plans to have VPATH support. Personally I do not fully understand the
concept, but suspect it to be a useful path translation mechanism. It is
being mentioned as an important feature elsewhere.

So the big question is:
Why on earth should we clone SCons in Ruby, if we choose to copy the concept
without bringing something unique to it.
Well - personally my need for a Ruby build system seems to have been
reduced.
But one answer would be: because you can!
Another answer is that it would be a natural fit to the planned Ruby IDE.
Third, it would allow standard build scripting to be done in our favorite
language.
Last and perhaps most importantly, it would allow for build tasks to be
written in Ruby - and you can so many cool things with a good buildsystem
that is only vaguely related to actually building software. In other words,
it is a good framework to have on top of the grand unified Torrent,
Distrubed Tasks framework.

So - assuming SCons proves worthy as a design model for a Rubuild System the
next question is:
Should it attempt to state compatible (not quite as ruby scripting is not
python scripting), or should it just pick the ideas and go its own way -
adding distributed builds with no regard to the future direction of SCons?
Going for compatibility - there might be a common interchange XML format not
unlike Ant, but also not quite the same because of the scanner objects and
generally different model.
You can't do everything in such a shared framework, but you could do a lot
things that way. It would assume keywords in the XML script would be
reflected in Ruby and Python objects respectively.
I'm not personally sure I like to involve XML in this, but if interoperation
is desireable, this may be the way to go.
If distributed builds are being implemented, one could also figure a way for
SCons and Rubuild to communicate via XML-RPC or similar.

Btw: What about an extra dependency step that builds libraries that doesn't
exists by downloading them automatically. This may be the RAA.succ idea
Robert Feldt mentions - but since I don't know about RAA.succ I can't tell.
Note that this has nothing to do with the build tool per se. It is just
another build task like zipping files or compiling. It's just dependencies
taken a step further.

The above is just a bit of brainstorming, and I haven't even looked closely
at SCons yet.

MikkelFJ