Re: [Caml-list] Installation of libraries with ocamlbuild

[skaller <skaller@users.sourceforge.net>]

On Mon, 2007-04-02 at 21:02 +0200, Daniel Bünzli wrote:
> Le 2 avr. 07 à 20:11, skaller a écrit :
> 
> > The caml development team alone does not have the expertise
> > to develop such a model in isolation: it requires a discussion
> > and feedback from the wider community.
> 
> Maybe, maybe not. I find it very usefull they want to tackle this  
> problem, so I'd like to encourage them instead of dismissing the idea.

I am certainly not dismissing it: I merely said it was premature
to implement something. Unlike type systems .. it's not entirely
a matter of logic: whatever is implemented needs to cope with
'the real world' .. :)

> > I personally think the proper solution is actually SOURCE not binary.
> > That is, you install sources .. never binaries. Ocamlbuild uses a
> > nominated cache directory for the binaries, and rebuilds automatically
> > any libraries required .. including when Ocaml itself is upgraded.
> 
> This could be the sketch an interesting solution.

This is what Felix actually does do right now .. *except* I haven't
done the 'cache' part. AFAIK Sun Java also does it, as do most
scripting languages with bytecode compilers.

It's not entirely trivial (parallel compilation of the same file
might cause corruption).

Unfortunately the 'programs are source code' view requires language
support: you basically can't allow the compiler to accept switches
like -o and -pack. In Felix the support is designed into the language
to make the 'programs are source' work. For example bindings to
C libraries have to be specified in the source code, it's done
like this:

	type gtkWindow = "GTKWindows" requires package "gtk-2.0";

and the compiler outputs a resource file of all the packages
required, which are then mapped via a package database
(like pkg-config) to shared library objects that need to be
linked in.

Ocaml doesn't have that support directly, however auxiliary
files are a reasonable solution, such as the ones
ocamlbuild uses, however it is important, IMHO, to ensure
the first level of those files uses *abstract* names not
file names.

Unix tries to do that with C compiler

	-Lpath -llib

switches where the -l argument is abstract and the -L maps it
to a filename.

Gerd tried to do that with ocamlfind, using meta-data.

Things get REALLY interesting with a cross compilation model.
It's fairly essential to make such a system work with cross-compilation.

The reason is that the additional difficulty actually HELPS get the
ideas sorted out. For example you'll note that camlp4 code executes
on a quite different machine than the final executable in that
scenario .. so even on a host you should have to give TWO paths,
one for camlp4 and interfaces, and another one for linking.

Or something .. i'm confused. It's actually a hard problem,
roughly equivalent to a parallel distributed lazy evaluator.


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net