Re: Request for comments: CONS specification

[H. S. Teoh]

On Thu, May 27, 2004 at 10:56:24AM +0200, Pierre THIERRY wrote:
> Hi all,
> 
> I'm still wanting to work on a CONS revival, so I'm thinking on the CONS
> specifications (more precisely, on its requirements). The first purpose
> was to figure myself what I would do, but as there are a lot of problems
> in CONS, specifying it from scratch will enable us to rebuild a CONS
> that will fit our expectations (and I don't even imagine to code without
> specs, actually...).

I'll be willing to contribute to the coding, if needed.


> 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. 


> In fact, they seem to be very simple:
[...]
> - the build tool should be able to guess the type of a result file,

I assume this would result from a table somewhere that tells it which
command produces what type of files? This table could be configurable, so
that it is easy to add new types (e.g. lex/flex files: .l -> .c, etc.)

[...]
> [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.

(However, also keep it mind that it *is* possible to write a TeX/LaTeX
file that will never reach a fixed point. We probably don't care for that
case, but it'd be nice if the build tool could be designed such that it
will never get stuck in such a loop no matter what the user does.)


[...]
> [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 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.


> With the above requirements, everything I know that can be built could
> be handled nicely: programs, documents (with style sheets, with preprocs
> and postprocs), archives, packages, etc. If you know something that
> don't fit in them, let me know.
[snip]

It looks good to me.  How about the interface for specifying new file
types? I assume that could be handled similar to the way it's done now?
(i.e., use declarations like
        FileType '.l', 'flex -o %s.c', ...;
.)


T

-- 
You haven't grown up until you're cynical enough.

signature.asc
Description: Digital signature