On Fri, 21 Dec 2001, MikkelFJ wrote:
>
> > You may want to look at Scons (www.scons.org):
>
> And so I did.
>

Since SCons is a descendant of Cons (written in Perl), and since
SCons is still in "alpha status", it could be interesting to look at
Cons too (as others have already mentioned).

I think anyone interested in Cons/SCons should read the article by
Bob Sidebotham (the original author of Cons) in the Spring 1998
issue of "The Perl Journal". The article is available online at

      http://www.samag.com/documents/s=1285/sam03010012/

That article got me hooked on Cons.
Since the article was written some years ago, it may not reflect
exactly how the current version of Cons works, but is still one of
the best ways to understand the major design ideas behind Cons.

I hope/think that SCons has taken all the good ideas from Cons,
and corrected some of the minor flaws in Cons that has been
noticed in the community of Cons users over the years.

>
> 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.

I cannot answer for SCons, since I haven't switched from Cons to
SCons yet. And I don't understand exactly what you mean.

What do you mean by "happens to be represented in two build objects" ?
If you clarified so I understand, I could prehaps give an answer for
Cons (and expect it to be valid for SCons too).

>
> 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.
>

I hope that there is some kind of "evolution" among the different
make substitutes. Unless a new tool is as good as, or preferably
better than previous tools, there is no compelling reason to invent
yet antoher make tool.

Sometimes I get the impression that every programmer want to write
their own make-tool. Initially it seems almost trivial: just a
depth-first traversal of a directed graph. But the more you look at
it, the more small details you discover. Making a really useful
make-tool is not trivial.

But of course it can be fun just trying ....

/Johan Holmberg