Re: Hmmm.... future of cons?

[H. S. Teoh]

On Tue, May 21, 2002 at 11:43:40AM -0400, address@hidden wrote:
> I get the feeling that cons _development_ has about run its course.  Even
> the original creator, Bob Sidebotham, as much as said SCons was the future
> and cons the past. 

Why? Other than the fact that people said it's over, that is.

> Although people have a lot of time and effort invested the only requests for
> _new features_ have been for parallel builds, and no one on the list seems
> to be itching to do the work. Maybe because the general feeling is that the
> real development is happening on SCons? 

I'm itching to add a user-friendly interface for defining new file types
and rules (e.g. a LaTeX builder I'm using on one of my personal projects).
I don't know if this has already been done -- I'm still using 2.2.0, and
the docs are frankly not very helpful to tell me whether such a feature
already exists.

And while I'm at it -- I'm also itching to figure out if there's a
fool-proof way of completely describing the dependencies of a LaTeX
document: you have the source file A.tex which produces a target A.dvi,
but also other stuff such as A.aux, A.toc, etc., all of which potentially
changes the input to LaTeX. A "correct" build would require some sort of
fixed-point algorithm (if one exists--I don't know, but I'm curious to
find out).

> I think a useful goal for someone taking over cons would be to get cons into
> a good resting state - fix the current web site, clarify the doc, integrate
> w/consplus, etc.  IMHO having a stable non-make solution till SCons gets
> fully up to speed is a worthwhile goal.  Rewriting it for clarity doesn't
> really seem all that useful to me - is there a real need for both a new perl
> and python solution?  The only real work being done is on SCons - whether
> that was a good call or not - and I assume thats where the new features will
> be going.

OK, I change my mind. A rewrite would probably not be the wisest thing.
But that doesn't mean an overhaul shouldn't be done. For one thing, split
cons into several files (possibly based on the package decls inside). A
first attempt can even just concatenate these scripts together into the
cons executable -- that way we don't have to worry about include paths and
so on.

As for SCons vs. Cons - I'm not familiar with SCons -- does it have
features that Cons doesn't have? If not, I see no reason for me, being
someone who knows Perl but not Python (and not very keen on picking up yet
another language), to not add new features to Cons, which already has the
richest existing set of features.

Just my $0.02.


T

-- 
A programmer is a device for turning computer programs into spaghetti. A good
programmer is a device for turning spaghetti into computer programs.