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

["Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl>]

skaller <skaller@users.sourceforge.net> writes:

> together these two functions conspire to determine which
> input files generate which outputs.

So I must either explicitly tell the dependencies, or run a script
which computes them. Same as in make.

Assume that I forget that compilation of a particular file also reads
another included file, i.e. forget one dependency link. Then after
changing the included file, the target will not be rebuilt (I don't
believe that it will, because then all other targets are in the same
situation and everything would be rebuilt, which is impractical).
So *all* dependencies must be specified. Same as in make.

The difference is in that that "changed" is determined by file
contents rather than time stamps, that compilation is repeated until
it stabilizes, and in the language the makefile is written in.

> If you try to include a file that is generated,
> all is well even if it is generated *after* you
> include it.

This implies that a compile error doesn't abort the compilation
(because the error might result from lack of source which will be made
later). So if I made a fatal error in a C header file included in many
C sources, the time to rebuild all of them and detect the error
multiple times will be wasted.

The time to compile good but out of date files is sometimes wasted too.
Imagine 3 modules:
   module A
   module B uses modules A and C
   module C uses module A
where "uses" actually means "reexports at least a part of it, such
that changes in one interface change the other". The modules happen
to be processed in this order. Someone changed module A. Then A is
recompiled; B is recompiled because A changed; C is recompiled because
A changed; B is recompiled *again* because C changed. 'Make' would
know that it makes no sense to compile B before C.

> More generally this will work even with circular
> dependencies, provided of course you design the
> system so it converges.
>
> As a counter-example: latex doesn't always converge.

It's the only counter-example I know.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

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