RE: Cons not working as advertized and other remarks and boddy new commers

[Steven Knight]

> > > A last word about Scons. (please let's keep the perl-python
> > > dumb war out of this list)
> >
> > You're pretty bossy for a newcomer. ;^)
> 
> 1/ Yes I am 8-), and that has nothing to do with being a newcomer. To get
> better kick yourself ,and others, forward.

Some of us do just fine kicking ourselves forward, thank you.  At least
then we can have some advance warning when the foot is going to meet our
hindquarters.

> 2/ You did not understood me. I DO NOT want any perl-pyhton war (I don't
> care). So if it is better written in VB, I will use it. I hope this will put
> a stop to this pointless discussion (that I started while wanting to avoid
> it)

But you apparently do want to start a pointless Cons-SCons war...? :-)

> > Steven decided that cons was the obvious choice for a
> > next-generation build tool.  But to qualify, it needed to be written
> > in Python.

Exactly the reasons.

> > Although I haven't taken a look at SCons yet, it sounds like the
> > developers have taken this opportunity to address some of the
> > architectural shortcomings of cons.
> 
> That was my question! If any shortcoming where addressed, which ones
> and in which way?  I looked at the Scons documentation and nothing
> stood there that pointed in that direction. Or did I miss it?

No, you didn't miss it.  I purposely did *not* write a "here's why
SCons is better than Cons" document because we don't need Yet Another
pointless religious war.  I didn't start the SCons project to be the
anti-Cons.  In fact, while developing SCons, I kept on finding things in
one tool that I wanted to adopt in the other, and vice versa.  I'd hope
that both would be able to continue to benefit from having the other as
an example of different design approaches that can be taken.

That said, here are some of the key architectural things that I tried to
address in SCons (based on my knowledge from having integrated most of
the Cons code over the past two years):

  - Make it easier to extend by allowing you to define new Builder and
    Scanner objects for new file types.  In Cons, these are hard-coded
    inside the script, and to create a new Builder or Scanner, you need
    to write some Perl for an undocumented internal interface.  In SCons,
    there are factory methods that you call to create new Builders and
    Scanners.

  - Modularity.  Cons is pretty monolithic.  SCons is designed from
    the ground up in separate modules that can be imported or not
    depending on your needs.

  - Embeddability.  The SCons build engine (dependency management)
    is separate from the wrapper "scons" script.  Consequently, you
    can use the build engine in any other piece of Python software.
    For exmple, you could even theoretically wrap it in another
    interface that would read up Makefiles (a la Gary Holt's
    make++ Perl script).

  - SCons dependencies can be between arbitrary objects, not just
    files.  Dependencies are actually managed in an abstract "Node"
    base class, and specific subclasses (can) exist for files,
    database fields, lines within a file, etc.  So you will be
    able to use SCons to update a file because a certain value
    changed in a database, for example.

  - Parallel build (-j) support.  Cons' recursive dependency descent
    makes it difficult to restructure for good parallel build
    support.  SCons was designed from the ground up with a
    multithreaded tasking engine (courtesy Anthony Roach) that will
    keep N jobs going simultaneously, modulo waiting for dependent
    files to finish building.

So far, thanks to the good fortune of having a great team of developers,
I think we're doing really well at attaining these goals.

        --SK