Re: Portability of applications written in OCAML: C stuff

From: Max Skaller (maxs@in.ot.com.au)
Date: Thu Feb 24 2000 - 03:55:57 MET

  • Next message: Xavier Leroy: "Re: CamlIDL and string options."

    Markus Mottl wrote:
    >
    > > The way these packages are distributed is a 'build in separate
    > > directory and install' model. This is NOT acceptable for my
    > > package. I require all components to be built and usable
    > > WITHOUT installing them (with one exception: the standard ocaml (and
    > > python)
    > > distributions).
    >
    > Hm, I don't know about "mlgtk", but what concerns the PCRE, you need not
    > install it anywhere to use it. The only thing you have to do is place
    > directory "{whatever}/pcre_ocaml/pcre-OCaml" on the include- and the
    > library path when you compile/link your project.

            This model doesn't really work for me. Consider that typically
    this requires

            1) run .configure
            2) run make

    This is not acceptable. My rules are: after the client untars the
    distribution of
    my product, they may have to edit part of the build script, 'maker'
    which is
    written in Python. Then they say 'python maker' and the build has to
    work
    without any other intervention. Make and autoconf are not permitted: any
    work
    these do must be done by ME in the 'maker' script IN PYTHON.

    In particular, while my product is currently Unix only, the build
    process
    must work under Windows too, which rules out make, autoconf, and other
    such silliness. :-)

    > "config.h" is generated by "configure" automatically and is actually part
    > of the C-library "pcre", which I always copy verbatim from its author.
    > Unless you also copy this "configure"-script out of its assigned directory
    > into your source dir, it won't do any harm to your files.

            pcre cannot build without config.h, and neither can mlgtk.
    So there is a conflict, since both require a file called 'config.h'.

    > > PLEASE use filenames that are specialised to your package,
    > > do NOT use generic names on the assumption your code will
    > > be built with your Makefile in a separate directory.
    >
    > This is impossible.

            It is not impossible to try.

    > How do you want to guarantee that files of other people
    > don't get overwritten if you mix some distribution with theirs?

            I guarrantee it, since I am combining the sources.

    > That's what directories are for!

            I do not wish to build and mess around with subpackages
    in directories, which amount to a small part of my overall package:
    pcre, for example, corresponds to a single library module with a few
    functions in it. There are hundreds of functions to build, and I want
    the sources all in the SAME directory.

            When ocaml supports packages with subdirectory structures natively,
    THEN I will require the client install third party packages, rather than
    distributing them as an integral part of my source.
     
    > I agree on this: a standard way for adding libraries, etc., would probably
    > boost productivity...

            Enormously -- but I will be happy to wait until it can be done
    right, since it is VERY hard to 'fix' a broken design here. {The python
    model is OK, but not perfect}

    -- 
    John (Max) Skaller at OTT [Open Telecommications Ltd]
    mailto:maxs@in.ot.com.au      -- at work
    mailto:skaller@maxtal.com.au  -- at home
    



    This archive was generated by hypermail 2b29 : Thu Feb 24 2000 - 15:34:58 MET