Re: Portability of applications written in OCAML: C stuff

From: skaller (skaller@maxtal.com.au)
Date: Fri Feb 25 2000 - 17:51:58 MET

  • Next message: skaller: "Re: Portability of applications written in OCAML: C stuff"

    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
    



    This archive was generated by hypermail 2b29 : Fri Feb 25 2000 - 18:16:05 MET