Evolution

[Bob Sidebotham]

It's called evolution, folks. Cons was a big advance over make, and
arguably has some advantages over jam, which was the source of its
original inspiration. Steven and his team have taken it to the next
level and are doing a superb job of crafting a beautiful tool. Cons
will continue to exist for a while, but I, for one, would rather see
Steven & his friends put their available energy into scons.

I'd like to take this opportunity to acknowledge all the hard work that
many people on this list have put into making cons a useful tool.
Steven and Rajesh both deserve special recognition for all they've
done.

Thanks!

Bob

--- Steven Knight <address@hidden> wrote:
> > > > 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
> 
> 
> _______________________________________________
> address@hidden
> http://mail.gnu.org/mailman/listinfo/cons-discuss
> Cons URL: http://www.dsmit.com/cons/



__________________________________________________
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com