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=AWL 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 12D7ABB83 for ; Wed, 13 Sep 2006 18:35:33 +0200 (CEST) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k8DGZUrR023648 for ; Wed, 13 Sep 2006 18:35:32 +0200 Received: from rosella (ppp14-47.lns2.syd7.internode.on.net [59.167.14.47]) by smtp3.adl2.internode.on.net (8.13.6/8.13.5) with ESMTP id k8DGZ4Tv072392; Thu, 14 Sep 2006 02:05:04 +0930 (CST) (envelope-from skaller@users.sourceforge.net) Subject: Re: [Caml-list] 3.09.3 release candidate 2 From: skaller To: Hendrik Tews Cc: caml users In-Reply-To: References: <0A29CC70-FA05-432A-9DF5-8B98F6E573F3@inria.fr> <4E2C1762-63F0-4540-8639-056C1C86528A@inria.fr> <1158161553.6133.236.camel@rosella.wigram> Content-Type: text/plain Date: Thu, 14 Sep 2006 02:35:04 +1000 Message-Id: <1158165304.6133.286.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 45083352.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; hendrik:01 tews:01 cmo:01 gramlib:01 camlp:01 cmxa:01 plexer:01 cmx:01 camlp:01 bytecode:01 cmo:01 grepping:01 gramlib:01 explicitely:01 runtime:01 On Wed, 2006-09-13 at 17:55 +0200, Hendrik Tews wrote: > > I do not understand why you do need .cmo files when you have a library > > (gramlib.cma or camlp4.cma) that includes these modules (note that .a > > and .cmxa are also available for native linking). > > But with this line of reasoning, plexer.{o,cmx} should not be > installed either, shouln't it? > > because these are *camlp4* modules, camlp4 loads bytecode > (only) dynamically from a single cmo file (only). > > No, for me it was like that: > - first I didn't know, there is library with these modules > (how to find out what library contains a given module without > grepping through the build log?) > - linking gramlib does not work, because the module is not > explicitely referenced (only during runtime the program does a > dynlink on something else that needs the given module) IMHO the real problem is that Ocaml doesn't provide a standard build model. It's a set of tools you have to couple together yourself in an ad-hoc way, which makes it very hard to build and distribute third party add-ons. Some 'standardisation' is provided by findlib architecture with meta-file descriptions. The problem propagates when upgrading: you have no idea where all the stuff is that requires recompilation to satisfy the new ABI. We need to compare this with Python, Perl, Java, or even Felix, to see that much better can be done: these systems find stuff more or less automatically, have specified layouts, and know when recompilation is required. This level of automation does not prevent fiddling with manual builds for special effects, but it eliminates the need to do so for many applications and libraries. In my view, there is no need for Inria to implement such technology: it can be developed by third parties. However to be really acceptable (a) Inria would need to participate in the development of the specification (b) modify the tools to support it if necessary (c) package the final solution with the standard distro (d) take over responsibility Similar to camlp4: tools like findlib are nice but you can't write build scripts that depend on them because not everyone has it, and even installing it won't help with already installed packages, or packages that don't themselves support it. If it were in the standard distro everyone WOULD support it (except for the special fiddles eg using patched Ocamls etc). I would note that 'Debian' or 'Godi' still only provide partial solutions -- they won't rebuild USER code bases automatically. The rule I use for Felix is: to run a program you say: flx source-code-filename arguments and everything else must be done by the system. The result of execution is defined in terms of SOURCE code, not binaries, so it is the system's responsibility -- not the users -- to locate all the required dependent sources, compile and link as required if cached copies aren't up to date, and run the code. In turn, the user is told how to make this work properly even for user components (and it is their responsibility to install the required meta-information). Not everyone will agree with this particular model and therein lies the real problem. Inria provides several ways to participate: (a) Join Inria (b) Join Caml Consortium (c) Put stuff on Humps none of which really give the community as a whole a political resolution process such as a Standards committee might, for the formation of a consensus. Most of us would agree to defer to Inria on issues such as the type system -- and most of us probably believe Inria would like to defer to the community on industrial issues such as building and distribution models -- but we have no 'forum' suitable for doing so. The Python community has a process involving PEPs (Python Extension Proposals) including web interfaces to track them, and processes to decide whether or not to accept them. I suggest the Ocaml Consortium consider opening up to a class of members 'ordinary user'. Such people join FREE, and are admitted if a couple of existing members or nominated persons vouch for them as bona fide interested parties. Such members can't spend consortium money, but they're free to contribute directly to it. The Consortium, in turn, will provide some resources to this body of people as it sees fit (eg some space on a web server, a Wiki, etc). -- John Skaller Felix, successor to C++: http://felix.sf.net