Re: [Caml-list] Announcing the OMake build system version 0.9.1

[skaller <skaller@users.sourceforge.net>]

On Mon, 2004-09-06 at 02:09, David Brown wrote:
> On Mon, Sep 06, 2004 at 01:08:13AM +1000, skaller wrote:
> 
> > Fixpoint iteration works and is universal.
> 
> It isn't universal, though.  There are pathalogical cases, even with common
> tools where it never will stabilize. 

I think it is very rare to find a case which would
stabilise with a manual order and not fixpoint iteration.

Clearly, the claim to universality means 'the result
will eventually converge to the same result as a correct
hand crafted solution'.

This claim isn't true. Every mathematician knows
there are functions with local maxima which are
not global maxima, and some algorithms which try
to converge on the maxima will pick the wrong one.

It is also possible to have processes which
are so badly degenerate unless they're started with
a sensible initial condition they just drop dead
immediately and never recover. I know all about this
one, since interscript is itself literate programmed
and used to build itself -- and a few times I got
a degenerate version with a hidden bug, installed
it as the fallback, only to find the bug propagated ..
and I had to manually edit the fallback Python script
and LP sources (in parallel) to get the bootstrap
converging.

So yes, you're right, but in practice this is very rare,
and its unlikely a conventional system would fare any
better.
.
> There are also some old Ada compilers that wouldn't build without proper
> ordering.  Fortunately, with Ada, the order can be determined from the
> source.

I don't understand. If there is an partial order, fixpoint
iteration should find it (eventually). It doesn't matter
if a build fails, as long as at least one extra step
succeeds each pass.

> I'm not sure if having a specific build order is a bad thing, I just think
> make's approach to determine it aren't right.

Of course it isn't a bad thing! The point is to regard
this kind of information as an optimisation. Fast builds
are important.

All real projects also contain test code, documentation,
and all sorts of other stuff much of which is generated,
and some of which is executed. And these relationships
aren't flat either -- sometimes you need to generate
a program to generate a program: in fact Autoconf
is a perfect example of a long (and fragile) toolchain.

The key thing is that the fixpoint just handles the lot
automatically in almost all cases. [This isn't theory,
I've been using it for well over a decade]

In particular, you can certainly make the building of, 
for example, Ocaml codes fast by specifying an order -- 
possibly by executing some tool that generates it.
[For the Felix project I just maintain a list by hand]

However, to do that for every single tiny part
of the system and get it right is probably quite
hard, even harder to maintain, and at worst
Goedel's theorem might intervene and make it 
completely impossible (since you'd have to manage
the code managing the code ...)

I guess the point I want to make here is that
make systems just don't scale in practice,
and that can't be fixed by extensions or new
versions of it because the fault is fundamental
to the concept of specified targets and dependencies.

We need new concepts, and I'm proposing a new
kind of solution: output tracking, convergence
to fixpoints, an executable high power
scripting system, a uniform packaging mechanism,
and dependencies treated as optimisations.

I'm not claiming interscript itself should be used:
just that the ideas be considered as an alternative
to the way make handles things. 

Interscript 1.0a11[123] Process Mon 06 Sep, 2004 04:22:36 (EST)
SKIPPING (files skipped last run, which did not converge)
BUILDNO 298
Unable to load sh tangler for "bagley/run.sh": using data
$Id: flx_maker.ipk,v 1.75 2004/09/02 13:52:14 skaller Exp $
Pass 1 status: <not converged>
  Files    : 277
  New      : 0
  Changed  : 1
  Unchanged: 276

You see it knows what has changed. And that one file
probably has the CVS time stamp in it or something
because this particular process never converges.
But it doesn't matter -- my program still builds :)

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners