Re: [Caml-list] Re: GODI vs. Ocamake

[Kenneth Knowles <kknowles@berkeley.edu>]

On Wed, Apr 14, 2004 at 09:54:27PM +1000, skaller wrote:
> Yes. I agree with this model. The first order of the day
> is to throw out make and replace it with a general purpose
> language + a library which make writing program building
> programs easier.

I agree here that make is not the end-all of building.  However, make is 
a language (shell) + a library (make itself).  The real problem is the library
is not written in the same language, and that both the language and the library
suck.

Re-implementing for different languages is a good idea.
 
> To put this another way, I regard 'autoconf' as one
> of the worst evils around. The correct solution is
> a combination of Standards and a full scale programming
> language -- not hacked up special purpose tools which
> are so grossly inadequate they need yet *another*
> tool to configure them .. and still don't work right.

I disagree completely here.  Autoconf is NOT a bunch of hacked up tools trying
to fix each other, but rather a set of programming modules in a support library
like you describe (albeit in weird languages).  Even with a library to make
writing program-building programs easier, it is a very intelligent division of
modules:

(1)  Adjust to current system
(2)  Accept compile-time parameters
(3)  Build system
(4)  Install system
(5)  Package system
(*)  More; like unit tests etc.
 
Autoconf *does* represent these modules, for the language of "shell/make/m4,"
with a target language of C.  Both python and perl have similar module
divisions (from my external users standpoint of having built modules for both).

Basically, what you should not assert is that "make" is even *supposed* to
perform any of the above except (3), or you are setting up a straw man.

It is nicer when the language used in the build process is more powerful/safe
than shell/make/m4.  It is also nice for it to be the same as the target
language, so no additional dependencies are introduced.

You may have a beef with GNU's choices of implementation languages.  Well I do
too, but I'm not surprised.  They also have a love affair with C, even for
high-level stuff.  I'm pretty sure we both agree that implementing the above
modules in OCaml, for OCaml, is the best thing to do. 

OCamlConf kind-of sort-of completes (1) and (2) and then outputs a makefile that
handles (3) through (5) pretty well.  I would be ecstatic to have (3) through
(5) written in ocaml, but haven't the time - thus my hope of possibly
integrating ocamake or similar thing for (3).  (4) and (5) are pretty trivial to
do by hand. 

Just so I don't leave anyone out, I'd say both ocamake and OCamlMakefile handle
(1) and (3) all at once.

If ocamlconf+ocamake became "ocamlbuild" then I'd still keep the userland steps
of: 
1. Accept compile-time options and check system compatability.
2. Build desired items
3. Install desired items

> [Interscript is a great python build tool]

To your benefit, I assume that within Interscript, there is modularization, and
it probably falls along similar lines.  Indeed, this sounds like exactly a
wonderful solution for python, but it is best for build and target language to
be the same - firstly not to introduce dependencies and secondly so developers
are immediately comfortable.

Kenn

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