Installation of libraries with ocamlbuild

Installation of libraries with ocamlbuild

[Joel Reymont]

What is a good way to implement installation of libraries with  
ocamlbuild?

--
http://wagerlabs.com/

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

[Nicolas Pouillard]

On 4/2/07, Joel Reymont <joelr1@gmail.com> wrote:
> What is a good way to implement installation of libraries with
> ocamlbuild?
>

There is no good way using ocamlbuild for now.

We plan to do it but that soon.

What I recommend is either a script shell that's does copy things out
of the build directory (there is an example in the OCaml CVS:
build/install.sh) or by using ocamlfind to install it.

-- 
Nicolas Pouillard

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

[skaller]

On Mon, 2007-04-02 at 19:00 +0200, Nicolas Pouillard wrote:
> On 4/2/07, Joel Reymont <joelr1@gmail.com> wrote:
> > What is a good way to implement installation of libraries with
> > ocamlbuild?
> >
> 
> There is no good way using ocamlbuild for now.
> 
> We plan to do it but that soon.

I'm not sure that is a good idea .. IMHO it's premature.
Installation is highly 'personal' and OS dependent,
might include docs, man page, etc etc.

Perhaps simply some way of saying what is to be installed,
and generating a manifest of files *to be installed*
without actually installing them?

Ocaml doesn't currently have a packaging model. This makes
things hard to find .. but until there is one, trying to
do it in an officially distributed tool might prejudice
a proper discussion of the requirements.

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

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

[Daniel Bünzli]

Le 2 avr. 07 à 19:22, skaller a écrit :

> I'm not sure that is a good idea .. IMHO it's premature.
> Installation is highly 'personal' and OS dependent,
> might include docs, man page, etc etc.

I'm sure it is a good idea. Only a standard coming from caml's  
development team is likely to be widely adopted. For example I  
personally don't use ocamlfind and find very annoying any library  
that _forces_ me to use it to install it.

I would be entirely satisfied by a very simple solution e.g. each  
library in its own directory in `ocamlc -where`, with everything in  
there (including documentation) according to a standard directory  
layout.

Best,

Daniel

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

[skaller]

On Mon, 2007-04-02 at 19:42 +0200, Daniel Bünzli wrote:
> Le 2 avr. 07 à 19:22, skaller a écrit :
> 
> > I'm not sure that is a good idea .. IMHO it's premature.
> > Installation is highly 'personal' and OS dependent,
> > might include docs, man page, etc etc.
> 
> I'm sure it is a good idea. Only a standard coming from caml's  
> development team is likely to be widely adopted.

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.

I personally use Ubuntu, which is Debian based .. but I don't
install Ocaml that way, I build it myself and put it in 
usr/local.

I also have Godi .. so I have two package managers on my
system already .. and ignore both.

I also run XP32, and XP64.

>  For example I  
> personally don't use ocamlfind and find very annoying any library  
> that _forces_ me to use it to install it.
> 
> I would be entirely satisfied by a very simple solution e.g. each  
> library in its own directory in `ocamlc -where`, with everything in  
> there (including documentation) according to a standard directory  
> layout.

That is one model, and one I would not like. I do not want
user libraries polluting the standard distro.

[Python does this .. and it crashes the debian installer
because I have my own code in the same place and it doesn't
compile .. and whoever wrote the python installer didn't
keep track of which packages belonged to Debian ..]

It is also not viable on multi-user systems, where the admin
installs Ocaml, but users install libraries.

I DO agree with you that a packaging model needs to be developed.

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.

The cache would be set by an environment variable.

So .. my model is probably quite different from yours.
Ocaml is very fast, but libraries are a nightmare because every
patch changes the ABI requiring everything to be rebuilt from
source. I personally solve THAT problem by not using any
third party libraries, other than those I actually put the source
of into my project and build as part of my project.

Python puts packages in the official install location .. 
and it crashes the debian installer because I have my own code 
in the same place and it failed to  compile after a version upgrade .. 
whoever wrote the python installer didn't keep track of 
which packages belonged to Debian, and didn't continue recompilation
after the error either.

What I'm saying is that it isn't a trivial problem.

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

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

[Daniel Bünzli]

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.

> It is also not viable on multi-user systems, where the admin
> installs Ocaml, but users install libraries.

Agreed. You'd need some kind of lookup PATH.

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

Daniel

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

[skaller]

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