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

I'm not too clear about the subject myself - but here are some thoughts:

In the simplest case you something like
with no particular syntax:

obj.Depend(main.obj,  main.c)
obj.Action("cc -c main.c -o main.o")

Here you have an object to be build.
But assume such objects can be generated in several ways.
For example using a filepattern selecting all *.c files in a directory.
Or by doing some dependency scanning.
How do you make sure that you do not accidentially generate an object that
really builds the same target.
I'm not sure it is impossible at all. The simple solution is to accept
multiple objects then when an action executes, it will look at the timestamp
and see that another object already build the file.
More advanced you could identify overlaps up front. This is what JAM does.

But what if build targets also cover things that are not physical files -
like sending emails. Or replication / downloading files where you can't know
that you already got it because you don't know how it looks like.
Or more basic: if the files are included via different include roots
(VPATH's). JAM is handling this. But what if multiple drives / symlinks map
to the same file: Obviously you can't detect everything. So signature /
timestamps will be used here.

In short - how do you internally identify multiple build objects that really
mean the same thing. And when should such a rule only execute once, and when
should it actually execute multiple times.

I think the concept boils down to some URN translation. File paths gets
expanded. Other kinds of resources gets similar canonical forms.
Should build signatures be stored as a physical file? JAM doesn't like make
"turds" as they write. Or should there be a build database with signatures -
a database that also handles resources which are not file based. In
distributed enviroments this would be a distributed database where each
build manager holds its own database controlled by some build namespace.

MikkelFJ