Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Re: Portability of applications written in OCAML: C stuff
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2000-02-25 (13:02)
From: Gerd Stolpmann <Gerd.Stolpmann@d...>
Subject: Re: Portability of applications written in OCAML: C stuff
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
>without any other intervention. Make and autoconf are not permitted: any
>these do must be done by ME in the 'maker' script IN PYTHON.
>In particular, while my product is currently Unix only, the build
>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

>> 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 Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 100             
64293 Darmstadt     EMail: (privat)