Re: Portability of applications written in OCAML: C stuff

[skaller <skaller@maxtal.com.au>]

Juergen Pfitzenmaier wrote:
> 
> Max Skaller wrote on Wed, 23 Feb 2000 10:43:46 +1100
> >         1. DO NOT USE A FILE CALLED 'config.h'
> ....
> >        do NOT use generic names on the assumption your code will
> >        be built with your Makefile in a separate directory.
> 
> I have seen some big projects (> 100 MB code) and several smaller ones. In each of
> them people had to fight with the configuration. They all settled for what seems to
> be the least pain: built and distribute (!) in small blocks; keep each block in its
> own directory; use the same general frame for each block if possible (yes: use the
> name config.h over and over again).
> Even if its leading away from OCaml: I think that your real problem is with "make"
> and its way of building project. Look for "configuration management" and "make replacement"
> on the net.

no thanks. you see, I have a vastly superior system.
It is called interscript. (http://interscript.sourceforge.net).
Interscript is a literate programming tool written in Python.
Interscript 'script' is Python too. This replaces _completely_
all configuration control, takes responsibility not only for
compiling target software -- and of course, documenting it --
but also testing and installing it.

Unlike like 'make', 'autoconf' and various lame shell scripts,
Python is a full scale general purpose programming language.

Interscript, being experimental, does not yet provide the uniform
language independent (and that includes human languages as well as
programming
languages) build platform I'd like it to, and it is a bit slow
generating
large documents.

For this reason, I an writing a fast, fully featured, Python compatible
interpreter call Vyper (http://Vyper.sourceforge.net), which is designed
to support later building of a compiler. Vyper is written in Ocaml.

The current version of Vyper is not literate programmed, and it won't be
until Vyper executes interscript satisfactorily. [One of the main hang
ups
is finalising Python class instance objects -- which means executing
their __del__ methods, in the correct order(ocaml 2.999 finalisers work,
but finalise the objects in the wrong order at present).

The combination of Vyper and Interscript will be a rather amazingly
powerful
tool -- compared with make, autoconf, and shell script.

Interscript programs are distributed as sets of text files. Rarely are
subdirectories needed, mainly because an interscript source is a level
of abstraction above a standard source code source file. [Interscript
itself,
for example, has a tree like directory structure of Python packages,
but the original sources typically contain a whole directory contents
in a few files (interscript is 'verging' on needing subdirectories for
the source).]

In a sense, interscript sources are 'self extracting archives'.
And unlike other methods of packaging 'free' or other software sources,
you _always_ get documentation (even if it is only a program listing :-)

As to autoconf -- it may well make sense to run it _once_ to build
a configuration library interscript can use to control the building
of software. But typically, the ability of interscript to _generate_
code provides a vastly superior method of configuration to hackery
like C macros, conditional compilation, and other weird C'isms
(that won't work with other languages).

So my aim is to eventually distribute Vyper as interscript source
(as interscript itself is distributed, together with a prebuild
version for bootstrapping). And that means I need to get rid of 
subpackage makes, autoconfs, and other things, so as to unify
the distribution mechanism.

So you see, you're quite right:

> Even if its leading away from OCaml: I think that your real problem is with "make"
> and its way of building project. 

but

>Look for "configuration management" and "make replacement" on the net.

I'be been programming for quite some time, and I know how the ludicrous
make
and configuration systems people use on systems, including Unix and
Windows,
work -- or should I say, _fail_ to work. This is well known. Why else
would Redhat, for example, have created rpm? (that doesn't work so well
either ..)

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net