Re: Request for comments: CONS specification

[Steven Knight]

Hi H.S.--

> > It will also be an occasion to take good ideas from other projects (I've
> > read the AAP tutorial, and I still need to give a look a SCons
> > documentation, if you have links on good build tools, I'd be glad you
> > send me some). Maybe we will have good ideas on our own, that I hoped
> > will be taken by other projects too. ;-)
> 
> AFAIK, SCons is essentially the same as Cons, with a few additional
> features. 

Not strictly true.  SCons took most of its inspiration from Cons classic,
but internally it's a complete redesign to correct many of the flaws
in the Cons architecture (monolithic, difficult to extend, lack of -j
support, etc.).  SCons would be a good source of ideas for any attempt
to redo or revive Perl Cons, as we've worked out a lot of kinks in how
to handle some complicated build situations in an improved (but still
somewhat Cons-like) architecture.

A few additional comments:

> [...]
> > [1] It is not the same as saying a file is up-to-date when its source
> > files have not been modified, when the building step involve more than
> > one pass (i.e. LaTeX).
> 
> Does that mean that the build tool should automatically iterate over such
> a process until a fixed point is reached? This may or may not be desirable
> (you'd need to run each step at least twice in order to know if a fixed
> point has been reached, but this would be a waste of time for
> straightforward things like gcc). Alternatively this could be made
> configurable, so that it would do this iteration only for "complex steps" 
> like LaTeX.

SCons handles this by actually looking in the aux file for the "ReRun"
message that indicates you should try to build it again.

> > [5] E.g. template steps, files types, source files guessing schemes,
> > distant systems methods, fetching methods, etc.
> 
> How deep should the source file guessing algorithm go? Conceivably
> multiple levels may be needed, e.g., lexer.o is built from lexer.c, which
> in turn is built from lexer.l. If lexer.c is missing, should the build
> tool still deduce that it should look for lexer.l ?

In general, being explicit about the source file is a lot less problematic
than guessing it.

The API design will require that the user will provide (in the minimal
case) two pieces of information:  the type of target to build (program,
object file, HTML file, etc.), and one file name.  You can have the user
specify this in two ways:

        I want to build a program from "lexer.l"

        I want to build a program named "lexer"

In each case, you're only specifying one file name.  But in the first
case, you can unambiguously deduce the target name from the source file,
and once you have the endpoints of the chain, you can figure out the
intermedate steps.  In the second case, you're forcing the build tool to
guess the source file name from the target name, and guessing introduces
the possibility of guessing *wrong*, which means you need a way to
disambiguate by allowing them to specify the source file name anyway...

> > In my view of what CONS should be able to, some project could be built
> > with very minimalist Constructs. For a LaTeX publication, for example,
> > only specifying the name of the Postscript file would be necessary. For
> > many programs or libraries, the name of the binary and a very small set
> > of object files should be sufficient (even the other needed object
> > files, according to the classes or functions they provide, could be
> > guessed).
> 
> I'm not so sure about automatically deducing class/function information
> from source files. That could make the initial scanning phase really slow.

It's not that bad, given a relatively efficient implementation. For
example, SCons actually scans .java files to figure out the .class
files that will result, which is downright necessary to support Java
correctly.  Without something similar, a Java compiler essentially behaves
"unpredictably" from the point of view of the build tool, because you
can't know in advance what targets will result.

        --SK