caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: skaller <skaller@users.sourceforge.net>
To: "Daniel Bünzli" <daniel.buenzli@epfl.ch>
Cc: Caml List <caml-list@inria.fr>
Subject: Re: [Caml-list] Installation of libraries with ocamlbuild
Date: Tue, 03 Apr 2007 04:11:10 +1000	[thread overview]
Message-ID: <1175537470.7492.17.camel@rosella.wigram> (raw)
In-Reply-To: <C7E3F6CD-B4D3-4622-ABEB-EF7404DB99BA@epfl.ch>

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


  reply	other threads:[~2007-04-02 18:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-02 10:37 Joel Reymont
2007-04-02 17:00 ` [Caml-list] " Nicolas Pouillard
2007-04-02 17:22   ` skaller
2007-04-02 17:42     ` Daniel Bünzli
2007-04-02 18:11       ` skaller [this message]
2007-04-02 19:02         ` Daniel Bünzli
2007-04-03  3:11           ` skaller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1175537470.7492.17.camel@rosella.wigram \
    --to=skaller@users.sourceforge.net \
    --cc=caml-list@inria.fr \
    --cc=daniel.buenzli@epfl.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).