Re: Hmmm.... future of cons?

Hi Doug--

A lot of good questions, here...

> I'll also say I don't really understand why Cons had to be re-written
> in Python.  I guess it's about the money.  Didn't the SCons project
> get money to re-write it in Python to be part of the Software
> Carpentry project?  

Actually, no.  That was the original plan, yes, but due to not getting
as much money from the sponsors as they originally thought, CodeSourcery
(the custodians of the project) ended up *not* funding the creation of
the build tool or the bug tracking system.  So SCons has been

I did get the prize for winning the design contest, but that was just
for the design document.  And when they decided not to fund creation
of the tool, I was offered a chance to produce another draft of the
document on a consulting contract, I believe as some sort of consolation
for not getting to build it.  I initially accepted the contract, but
couldn't muster any enthusiasm to write yet another draft of an already
fleshed-out design in my head, so I resigned the contract after two
months without submitting any time sheets.

Consequently, all of the real work on SCons has been strictly volunteer.

>                     Was that the only reason?  Were there technical
> reasons for abandoning the Perl code base?  

Some technical reasons, although they could have been worked through,
with time.  The biggest technical issue is the Cons recursive dependency
descent being very much at odds with the SCons model for parallel
builds.  There is also a lot of desirable modularity that would be a
chore to stitch into the current Cons structure.

However, there were two other reasons that prompted me to go off and
start SCons, instead of working within the Cons structure:

First, since I'm not the Cons project lead, I would have had to fork
the project in order to move as rapidly as I wanted, due to issues like
updating the web site, etc.  Forking would, I think, have been a Bad
Thing.

Second...

>                                             I don't really know
> Python.  I've only done a smidgen of work in it.  However, I don't see
> anything that Python does that Perl doesn't do just as easily.  True,
> the syntax is more "homogeneous"; however, TMTOWTDI is one of the
> things I like most about Perl.  

...Second, I love Perl, but I really do think that it's a significant
barrier to acceptance of Cons.  TMTOWDI is great for programmers, but
I've bought in to Software Carpentry goal of setting out to make a build
tool that has all of the advantages of the Cons architecture *and* is
reasonably friendly to non-programmers, as well.  Now that I've worked
with it for almost a year, I can tell you that I think Python does win
this battle, hands down.

>                                 Anyway, this seems like a perfect
> example of Joel Spolsky's Rule Number One[1].
> 
> [1] http://www.joelonsoftware.com/articles/fog0000000069.html

Funny you should mention this, because I've recently become a big
believer in Spolsky's rule one, much to the consternation of some of the
people I work with.  (I've been squashing "rewrite" projects lately...)
I can, however, make a pretty good case that SCons is setting out to
accomplish some different goals than Cons.

In addition to the usability issue mentioned above, SCons' modularity
and ease of adding new Builders is lending itself extremely well to
absorbing a lot of autoconf functionality.  A developing goal is to make
SCons flexible enough and smart enough, and to provide it with enough
out-of-the-box functionality, so as to eliminate the need for autoconf
altogether--or at least, eliminate use of autoconf for Makefile work.

Could Cons have done this as well, with enough work?  Sure; it's only
software, after all.  But go back to the other recent email messages
suggesting that Cons is pretty "feature complete."  That's true if
you're looking for a simple, reliable dependency manager that gives you
Perl hooks for your own stuff--and there's nothing wrong with that.

But if you take a look at the Cons TODO list (included in your
distribution!), you'll see that there's still a lot that *could* be done
with Cons: provide support for more tools and file types out of the box;
collect and clean up all of the individual patches people have made to
it; fold in the Cons::Plus extensions and Greg Spencer's NT extensions;
make it easier to define your own Builders, better error messages and
build debugging, etc., etc.  (SCons is actually ahead of Cons on a
number of these issues, despite being behind in other areas.)

I think the key question now is what sort of appetite the Cons community
has for this sort of continued work, because *that* will determine what
sort of tool Cons might or might not be.

	--SK, stepping back down off his soapbox


_______________________________________________
[email protected]
http://mail.gnu.org/mailman/listinfo/cons-discuss
Cons URL: http://www.dsmit.com/cons/