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.1 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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 3B273BC6C for ; Wed, 30 Jan 2008 16:12:16 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAFQioEfAXQImh2dsb2JhbACBWI5PAQEBCAopnzIB X-IronPort-AV: E=Sophos;i="4.25,277,1199660400"; d="scan'208";a="7434324" Received: from discorde.inria.fr ([192.93.2.38]) by mail1-smtp-roc.national.inria.fr with ESMTP; 30 Jan 2008 16:12:16 +0100 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m0UFCFiH022389 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Wed, 30 Jan 2008 16:12:15 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAFQioEfU4366nmdsb2JhbACBWI5PAQEBAQEGBAYHChifMgE X-IronPort-AV: E=Sophos;i="4.25,277,1199660400"; d="scan'208";a="7434322" Received: from moutng.kundenserver.de ([212.227.126.186]) by mail1-smtp-roc.national.inria.fr with ESMTP; 30 Jan 2008 16:12:15 +0100 Received: from gate.lan.gerd-stolpmann.de (dslb-084-059-121-081.pools.arcor-ip.net [84.59.121.81]) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis) id 0MKxQS-1JKEbk0L0Y-000571; Wed, 30 Jan 2008 16:12:14 +0100 Received: from [192.168.0.32] (fw.lan.gerd-stolpmann.de [192.168.1.1]) by gate.lan.gerd-stolpmann.de (Postfix) with ESMTP id 46FC0C110; Wed, 30 Jan 2008 16:12:11 +0100 (CET) Subject: Re: [Caml-list] Re: [OSR] Ports-like package management system From: Gerd Stolpmann To: Stefano Zacchiroli Cc: caml-list@inria.fr In-Reply-To: <20080130133741.GB20725@takhisis.invalid> References: <479F0664.2070706@exalead.com> <20080130123705.GA21900@pulp.rsise.anu.edu.au> <1201702034.9179.59.camel@flake.lan.gerd-stolpmann.de> <20080130133741.GB20725@takhisis.invalid> Content-Type: text/plain Date: Wed, 30 Jan 2008 16:12:15 +0100 Message-Id: <1201705935.9179.102.camel@flake.lan.gerd-stolpmann.de> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1+ExqWuk8PI05mKQZ3JrSGVDRjqFBSc5PzlFAb KhVThgur/GC8V7Z+3rPdnpqXvablQEAuk56GAeS5zi0Zq0YTtk +4VkMwDupqQa61v8XIhbxzjmuTK0GSi X-Miltered: at discorde with ID 47A093CF.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; gerd:01 stolpmann:01 zacchiroli:01 0100,:01 gerd:01 stolpmann:01 bytecode:01 semantics:01 ocaml:01 bytecode:01 nativecode:01 ocaml:01 compilation:01 ocaml's:01 dependencies:01 Am Mittwoch, den 30.01.2008, 14:37 +0100 schrieb Stefano Zacchiroli: > On Wed, Jan 30, 2008 at 03:07:14PM +0100, Gerd Stolpmann wrote: > > My suggestion is this: A driver file "Obuild" that descriptively says > > which build tools (out of some generally accepted options) are supported > > by this piece of software. Example for Obuild: > > > > configure_script: configure > > build_tool: GNU make > > make_bytecode_target: all > > make_native_target: opt > > make_install_target: install > > supports_prefix: true > > I like this proposal in general, and the above example targets sound > reasonable. However, I would like to stress that some semantics > associated to the above name should be clarified somewhere. For example, > here is a sampling of questions I've found differently answered in my > experience of Debian packages of OCaml software: > - does the make_install_target above installs bytecode, nativecode, > both, the "better" of the two? > - does the make_native_target above requires that make_bytecode_target > has been invoked first? Fully agreed that we need a reference document for this. > The answers might seem obvious, but I assure you that there are an > unbelievable number of different combination of them in the OCaml > distributed softwares out there. The compilation of random C libraries > is far more standardized that OCaml's; this is probably our chance to do > the same. > > Also, you would need to support "custom" build tools in which you are > just told to run a given command. Extlib for example needs you to run > "./install.ml" in order to be installed ... > > > What's left out are dependencies. They make only sense as a system, > > and managing a system is a different story. That should be left to > > packagers like GODI or Debian. > > > Well, as said, I suggest to leave out dependencies. A dependency error > > in a single uploaded package can make the whole tree unbuildable. Deps > > are outside the scope of loose cooperation. > > I don't follow you here. > > First of all the OCaml namespace of distributed software ATM is quite > well defined even if we have had so far no common place where to upload > stuff. So we can rely in general on names being unique. Then, I would > like to have in an Obuild file the declaration of which other OCaml > softwares I need to build that one (i.e. I'm talking about *build* > dependencies here, not runtime/development time dependencies). Why such > a requirement isn't reasonable? You are basically proposing a > declarative specification of the build process of a distributed > software, I consider build dependencies a fundamental part of such a > specification. > > Or where you talking about runtime/development time dependencies? See, this question already demonstrates that dependencies are a not so easy concept. It is at least difficult to reach a common understanding what would have to be listed as dep and what not. We have dependencies that come into play at different times, and there are also conditional dependencies (i.e. you need this software only if you want to build this special feature). Then there is the question of how detailed the dependency relation is (versions, or about allowing to have only parts of software units as dependency). A formalization of deps needs some complexity in order to be useful, but that makes a common understanding of them more difficult. I have some doubts that we find a balance here, so my advice to leave a formal description of deps out. Gerd -- ------------------------------------------------------------ Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de Phone: +49-6151-153855 Fax: +49-6151-997714 ------------------------------------------------------------