Re: Portability of applications written in OCAML: C stuff

[Gerd Stolpmann <Gerd.Stolpmann@darmstadt.netsurf.de>]

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