Re: Request for comments: CONS specification

[Pierre THIERRY]

> The main barrier to adding this to the current version of Cons is that
> its current monolithic design makes it very difficult to do [parallel
> building] without major overhaul of the code.

I think that if we refactor Cons in clean way, new features will be very
straightforward to implement. If everything is very modular, inserting a
new module on top or inbetween should be easy.

> > I think iteration should have four modes: none, fixed, limited and
> > infinite. [...]
> Perhaps a better way would be to only run everything once, unless the
> user says to make sure the target is at a fixed point

I like one the design goals of SCons, which I see as one of mine, but in
a very particular point of view: a non-hacker should be able to use
SCons to build something.

When I download a tar.gz, and start the compilation, I expect having
just to do ./configure --prefix=/usr/loca/ && make && make install. I
should not have to provide special options the obtain a stable build.

-> Simplicty

Instead, the developper, who knows its build tool, must have the ability
to speedup things by bypassing somes securities or warnings.

And last but not least, this iteration thing should be fine tuned for
each language. In C/C++, this would be disabled by default, and for TeX,
we should include tests for Cons to know whether iterating is worth
(e.g. the ReRun in the aux file).

> Only when you want to do a final shipping build, you want to make sure
> everything is consistent. So it should be OK to just run TeX once
> during development, and only run it in "full" mode when you want a
> final build where everything must be consistent.

The default prupose of the build tool must remain building consistent
things. The developper would build a variant, with iteration disabled.

-> added Flexibility

somthing like:

cons --variant "quick'n'dirty" foobar.dvi

> > CONS would build recursively a graph with the possible ancestors of
> > the files it has be given.
> This could be possibly be cached for speed

Yes, one of the main purposes of a build tool is avoiding doing things
again when it's not needed.

> in the .consign file (or some other startup file)

I think we'll avoid having a monolithic design even here. A .cons
directory will be far more flexible.

> The problem now is that Cons wouldn't know whether main.c would be
> produced or main.cc should be produced, unless the user specified it
> explicitly.

There are a lot a ways of solving this ambiguousity: either giving Cons
what the default language is for the build (either all the build, or for
a particular subdirectory) or having a way to find out in the Flex or
Bison files what the target type is.

> Another problem is that *many* possible source file types are compiled
> into .o files, and there may be a large graph of possible sources for
> each .o file specified by the user. This might slow down Cons, if it
> has to check through a long list of possibilities each time, plus
> resolve ambiguities in the graph each time.

It's not a big deal for modern CPUs to handle such graphs. There's a lot
of stable algorithms out there to walk and build graphs (use Graph;).

> Or perhaps I'm just expecting too much...

Surely not, in my point of view, you don't expect enough!

> maybe we can force each file type to only ever produce a fixed set of
> outputs, so Flex .l files will be assumed to only produce .c unless
> the user explicitly overrides this.

We should never make assumption that have no serious justification. If
Flex can produce C++, Objective-C or anything else, it would be a grave
bug that Cons, by default, consider it outputs C files only.

> Probably we don't need to worry about the .s file? It's probably safe
> to assume that for the common case, we'll always compile a .c file
> into .o "directly".

Cons must be aware that there are intermediate steps. And for each set
of tools it will know about, it will also know if, by default, they
/forget/ these steps, or make them implicitly...

> I think maybe we shouldn't worry too much about the complicated cases;

If we don't, we lose all benefits of a complete specification. We must
consider the most weird situations in which Cons could be used. We maybe
won't write actually the subsystems for these situations, but the Cons
architecture won't prevent someone to do it.

Else, we will, some day, have a feature that is impossible to add,
similar to the parallel building today. And I don't rewrite Cons today
to have to rewrite it a second time later! ;-)

> If the user needs to do something special, he should just explicitly
> specify what he wants.

Yes, the guessing model must not be mandatory. When it reaches its
limits, you will deal with your build without it, or by helping it with
some information.

> Good point. I think it might make sense to refine the dependency graph
> *during* the build process.

Happily, it will not be needed in most cases.

> The other possible solution is for the .l file type definition to
> state explicitly that the resulting .c file will always have a
> dependency on some corresponding .h file

I would consider it as a bug, again. If our guessing system don't work
in a particular situation, we must not insert dirty hacks in it to
bypass the problem.

> The problem is that for many programming languages, deducing
> class/function dependencies amounts to parsing the source file(s) and
> building a symbol table --- things which should be done by the
> compiler, not by Cons.

Some compiler may provide a interface to do that. I agree that Cons must
not become a semi-compiler.

> Unless it's not possible for the computer to guess the user's
> intention, in which case the user *should* be able to specify the
> missing information without needing to specify *everything* explicitly
> from scratch.

Yes. The user should always be able to trigger the build by giving the
bare minimum of unambiguous information.

> > In fact, with this spec, we could, IMHO, say CONS will be something
> > like an expert agent more than a simple build tool.
> Sure, we can try. :-)  There are some things that just can't be solved
> without the user telling us what to do, though. E.g. the XML example
> above.

Yes, until we have a complete AI that learns from the user's preceding
works how he names his files... ;-)

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

signature.asc
Description: Digital signature