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 discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 2D053BC0A for ; Tue, 3 Apr 2007 05:16:22 +0200 (CEST) Received: from ipmail02.adl2.internode.on.net (ipmail02.adl2.internode.on.net [203.16.214.141]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l333GI0r031581 for ; Tue, 3 Apr 2007 05:16:20 +0200 X-IronPort-AV: E=Sophos;i="4.14,363,1170595800"; d="scan'208";a="105501098" 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 12:41:07 +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: <93C44656-2FF9-43C0-862B-80A9654BFEAA@epfl.ch> References: <8803983E-0B1E-4A11-BAF3-D18C7BA67607@gmail.com> <1175534543.5440.6.camel@rosella.wigram> <1175537470.7492.17.camel@rosella.wigram> <93C44656-2FF9-43C0-862B-80A9654BFEAA@epfl.ch> Content-Type: text/plain; charset=utf-8 Date: Tue, 03 Apr 2007 13:11:04 +1000 Message-Id: <1175569864.7492.57.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 8bit X-Miltered: at discorde with ID 4611C702.002 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; 0200,:01 model:01 usefull:01 ocaml:01 afaik:01 bytecode:01 trivial:01 compilation:01 compiler:01 -pack:01 bindings:01 compiler:01 ocaml:01 gerd:01 ocamlfind:01 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 Felix, successor to C++: http://felix.sf.net