Version française
Home     About     Download     Resources     Contact us    
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: -- (:)
From: Max Skaller <maxs@i...>
Subject: Re: Portability of applications written in OCAML: C stuff
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