From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id F237DBC0A for ; Mon, 2 Apr 2007 20:11:18 +0200 (CEST) Received: from ipmail02.adl2.internode.on.net (ipmail02.adl2.internode.on.net [203.16.214.141]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l32IBGDL005002 for ; Mon, 2 Apr 2007 20:11:18 +0200 X-IronPort-AV: E=Sophos;i="4.14,362,1170595800"; d="scan'208";a="105326468" Received: from ppp36-111.lns2.syd6.internode.on.net (HELO [192.168.1.201]) ([59.167.36.111]) by ipmail02.adl2.internode.on.net with ESMTP; 03 Apr 2007 03:41:15 +0930 Subject: Re: [Caml-list] Installation of libraries with ocamlbuild From: skaller To: Daniel =?ISO-8859-1?Q?B=FCnzli?= Cc: Caml List In-Reply-To: References: <8803983E-0B1E-4A11-BAF3-D18C7BA67607@gmail.com> <1175534543.5440.6.camel@rosella.wigram> Content-Type: text/plain; charset=utf-8 Date: Tue, 03 Apr 2007 04:11:10 +1000 Message-Id: <1175537470.7492.17.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 8bit X-Miltered: at concorde with ID 46114744.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; 0200,:01 caml's:01 model:01 ocaml:01 usr:01 ocamlfind:01 ocamlc:01 -where:01 model:01 polluting:01 distro:01 ocaml:01 rebuilt:01 trivial:01 sourceforge:01 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 Felix, successor to C++: http://felix.sf.net