Re: Portability of applications written in OCAML: C stuff

From: Gerd Stolpmann (Gerd.Stolpmann@darmstadt.netsurf.de)
Date: Thu Feb 24 2000 - 21:17:51 MET

  • Next message: Max Skaller: "Re: Calling C from OCaml, GC problems"

    On Thu, 24 Feb 2000, Max Skaller wrote:
    >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. :-)

    We all know that Windows is not a serious operating system because it lacks
    support for many tasks we all EXPECT from an operating system. This is one of
    the reasons why I do not offer Windows support for my components. You have only
    two possibilities: (A) reinventing the wheel by writing tools yourself; (B) not
    offering special Windows support.

    Please don't blame us that it is difficult to implement (A).

    I would say that your build process is ... mhhh ... strange. If I did it
    with only limited means, I would still distinguish between source directories,
    and a (temporary) installation directory, say:

    lib: the installation directory
    source1, source2, ...: source directories

    Simply compile the sources one after another (in a fixed order), and install
    the results in lib. While compiling the sources, include -I ../lib such that
    the previous results can be used in the next compilation step. This is simple
    enough to be implemented even without Makefiles and autoconf.

    >> "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'.

    As far as I know you cannot choose the name of "config.h"; this is hard-wired
    in autoconf.

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

    Your argumentation is ridiculous. I often have directories with only very few
    files if there good reasons to create them. In general I would argue that
    directories reduce the mess.

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

    Why do you need a "native" package implementation? I think there are good
    reasons to have one (e.g. a uniform installation procedure), but in your case
    you can use ANY package mechanism (I have one), simply distribute it with your
    sources.

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

    What does "right" mean? It depends on your expectations. For example, I
    think a package mechanism should not include any build functionality (some kind
    of "make") because there are already good solutions (even for Windows (cygwin)).

    Gerd

    -- 
    ----------------------------------------------------------------------------
    Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
    Viktoriastr. 100             
    64293 Darmstadt     EMail:   Gerd.Stolpmann@darmstadt.netsurf.de (privat)
    Germany                     
    ----------------------------------------------------------------------------
    



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