Re: Request for comments: CONS specification

[Pierre THIERRY]

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

Great.

> AFAIK, SCons is essentially the same as Cons, with a few additional
> features.

OK. Does someone using SCons could list those features?

> 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 [...] Alternatively this could be made configurable, so that
> it would do this iteration only for "complex steps" like LaTeX.

Yes, it would be a nonsense to trigger every build, assembly and link
twice. I think iteration should have four modes: none, fixed, limited
and infinite. The latter being dangerous, as you told some TeX files can
endlessly change, and it's already the case when there is tiemstamping.
Fixed mode should iterate a given number of times, and limited would
iterate until stability or a maximum numer of times (maybe issuing a
warning if limit is reached).

Apart from TeX, I think that iteration could also be of interest for 3D
rendering (I know applying some raytracing algorithms can need such
successive iterations be accurate).

> How deep should the source file guessing algorithm go?

In my understanding, each file type should have attached ancestors
definitions (this could be simple strings, regex substitutions,
functions or even external software calls). CONS would build recursively
a graph with the possible ancestors of the files it has be given.

The first present ancestor found in this graph would be used as the
source file.

Example with C++:

        Target ["helloworld"], ["main.o", "hello.o"];

And the directory contains a main.l (don't know this language, but you
told it can be source of C, let's go with it...), hello.cpp and hello.h.

This could give following graph:

                              helloworld
                             /          \
                       main.o            hello.o
                         |                  |
                       main.s            hello.s
                         |                  |
                      main.cpp          hello.cpp
                         |                  |
                       main.l            hello.l

CONS go through the graph until it finds a way to build each given file.
This would give the following dependency graph:

                              helloworld
                             /          \
                       main.o            hello.o
                         |                  |
                       main.s            hello.s
                         |                  |
                      main.cpp          hello.cpp
                         |
                       main.l

Then, CONS would also scan the existing files for dependencies. The .l
scanner could tell that a hello.h is needed to build main.s:

                              helloworld
                             /          \
                       main.o            hello.o
                         |                  |
                       main.s            hello.s
                      /      \              |
               hello.h        main.cpp  hello.cpp
                                |
                              main.l

Here is our final dependency graph. Now CONS can trigger the build
process, and knows when a rebuild is needed...

In this guessing model, there remain a question that appeared to me with
this ".l" format: it could, with some prepocessors, be necessary to scan
result files for dependencies, thus having a dependency graph that
changes during the build process.

It has two drawbacks: the analysis of the dependencies can be inaccurate
without building, and then displaying the actions without actually
building can be also inacurrate. But the situations where this problem
can arise seem to me to be fairly rare, and are easy to bypass, by
giving the hidden dependencies explicitly (you just loose the benefit of
CONS guessing everything for you).

CONS should also warn the user if he finds new dependencies while
building. (in fact, it should not search them for languages where the
problem is impossible, like C/C++ without predecessors)

> I'm not so sure about automatically deducing class/function
> information from source files. That could make the initial scanning
> phase really slow.

This will be a user's choice. If he's lazy and he considers the scanning
time is bearable (and it's not sure it would be really slow...), he lets
CONS do its job, else he can just provide dependencies, like he used to
do...

> It looks good to me.

Good news!

> How about the interface for specifying new file types?

Their should me multiple ways, from the simpliest to the more flexible.
A filetype could be defined with a filename list (makefiles), a suffix
(most of the cases) or even regex, function or program call (like the
'file' utility in UNIX).

Separately, steps would be defined with the types of their result and
source files. e.g.:

- ( xml + xslt => xml )      = xslt processor
- ( source     => assembly ) = assembler
- ( object     => program )  = linker

Then, the specific 'xslt processor' could have multiple alternatives
(xsltproc, xalan, sablotron, etc.), which could be used by CONS to adapt
automatically to its environnement.

The goal is always the same: the lesser information the user has to give
CONS, the better it is. Because when the computer can do it, the user
should not have to...

In fact, with this spec, we could, IMHO, say CONS will be something like
an expert agent more than a simple build tool.

Artificially intelligent,
le Moine Fou
-- 
address@hidden
OpenPGP 0xD9D50D8A

signature.asc
Description: Digital signature