English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
[Caml-list] Announcing the OMake build system version 0.9.1
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-09-05 (05:21)
From: skaller <skaller@u...>
Subject: Re: [Caml-list] Announcing the OMake build system version 0.9.1
On Sun, 2004-09-05 at 05:59, Matthieu Dubuget wrote:
> chris.danx a écrit :
> > Nicolas Cannasse wrote:
> >> However, I can't help thinking that I don't write to learn yet another
> >> language for writing my Makefiles... Why not using directly OCaml for
> >> writing Makefiles and exposing all nice OMake features through a 
> >> library ?

> May be YaM is a first step toward this. YaM was written by Damien Pous:
> http://perso.ens-lyon.fr/damien.pous/shared/ocaml/YaM/

My personal take is: all 'make' based build systems
are fundamentally flawed because they're based on
the wrong concept. 

The basic problem is that make assumes a fixed set
of target outputs and has rules like:

	A depends on B: use P to make A from B

This means you have to know all the outputs,
dependencies, and build rules in advance
which is *never* the case on any realistic system.

The way forward is to rethink the fundamentals.
Interscript works like this:

	if anything changes rebuild

This rule is universal. Rebuild rules are arbitrary
executable code,  the process is terminated by
detecting a fixpoint, which it can do by tracking
all outputs.

The logic here is reversed. You execute a 'rule'
because it is part of an unfixed build
(a process that hasn't converged to a fixpoint)
NOT because you need to satifsy a dependency.

The problems are ones of optimisation, 
not working around the fact 'make'
is both incomplete and unsound. In other words,
we can use mathematics to reason about how
to optimise it, rather than trying to 'improve'
something which is fundamentally broken.
[Adding optimisations to a universal solution
is fundamentally different to extending an
incomplete one]

For Omake -- the 'automatic file system monitoring'
is not merely a 'convenience' to save typing 'omake'.
Rather it should be viewed as *fundamental* change
to the usual build paradigm -- its a step in the right

It should solve the following equation:

	d.dvi,d.aux = latex d.tex,d.aux,d.dvi

which is necessary to use latex. (The aux file
holds location of labels which are needed to
generate forward references whose size may
change with the location which may change the
locations of labels ..)

In interscript, I use dynamic code generation.
This is very clumbsy -- print out a Python
file then use 'execfile' to execute it.

Some kind of more advanced partial evaluator
is probably the way to go.

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