Request for comments: CONS specification

[Pierre THIERRY]

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

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

In fact, they seem to be very simple:

- the build process consists of one or more steps,
- each step consist of passing zero or more source files to a processor,
  that will output one or more result files,
- a result file is said up-to-date if doing the step that output it
  would output it identically[1],
- a step depends on another step if the source files of the former are
  the result files of the latter,
- the connection of all steps to the ones they depends on is called the
  dependency graph,
- a step can only be triggered when all steps it depends on have been
  succesful,
- some steps can be /forgotten/, i.e. their result files can be erased
  when all steps depending on them have been triggered,
- some processors make intermediate steps implicit or /forget/ them
  automatically, some of them being able to explicit them back[2],
- the build tool should be able to trigger steps in parallel,
- the build tool may be able to run steps locally or on a distant
  system[3],
- the build tool may be able determine, on a system used to build, if
  all components needed are available,
- the build tool may be able to adapt the steps to the available
  components,
- the build tool should be able to manage variants of the result files,
- the build tool should be able to remove all result files,
- the build tool should be able to remove a given variant of all result
  files,
- the build tool may be able to remove some result files, based either
  on their name, type or position in the dependency graph[4],
- the build tool may be able to fetch source files,
- the build tool should be able to guess the source files of results
  files of a known type,
- the build tool should be able to guess the type of a result file,
- the build tool must provide a simple way of defining its
  components[5],

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

[2] E.g. source>assembly>object>binary is seen as source>object>binary,
or even source>binary, but you can tell GCC to output all intermediate
formats.

[3] It has two purposes: benfit the processing power of a better system,
or running steps in parallel on many systems, notably when the local one
would not be able to run them in parallel efficiently.

[4] E.g. remove result files of all non-terminal nodes of the graph, to
only keep the final result.

[5] E.g. template steps, files types, source files guessing schemes,
distant systems methods, fetching methods, etc.

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

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.

Methodically,
le Moine Fou
-- 
address@hidden
OpenPGP 0xD9D50D8A

signature.asc
Description: Digital signature