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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 3015ABC6C for ; Wed, 30 Jan 2008 15:42:36 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAAAcoEfAXQInh2dsb2JhbACQJwEBAQgKKZ8k X-IronPort-AV: E=Sophos;i="4.25,277,1199660400"; d="scan'208";a="8539953" Received: from concorde.inria.fr ([192.93.2.39]) by mail3-smtp-sop.national.inria.fr with ESMTP; 30 Jan 2008 15:42:19 +0100 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m0UEgCAg000679 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Wed, 30 Jan 2008 15:42:19 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAEsboEdDz4He/2dsb2JhbACwDA X-IronPort-AV: E=Sophos;i="4.25,277,1199660400"; d="scan'208";a="6746012" Received: from fettunta.fettunta.org ([67.207.129.222]) by mail2-smtp-roc.national.inria.fr with ESMTP; 30 Jan 2008 15:42:18 +0100 Received: from aquarium.takhisis.invalid (unknown [10.17.0.10]) by fettunta.fettunta.org (Postfix) with ESMTP id BBA271858D for ; Wed, 30 Jan 2008 14:42:17 +0000 (UTC) Received: by aquarium.takhisis.invalid (Postfix, from userid 1000) id 75078124C33; Wed, 30 Jan 2008 14:37:41 +0100 (CET) Date: Wed, 30 Jan 2008 14:37:41 +0100 From: Stefano Zacchiroli To: caml-list@inria.fr Subject: Re: [Caml-list] Re: [OSR] Ports-like package management system Message-ID: <20080130133741.GB20725@takhisis.invalid> Mail-Followup-To: caml-list@inria.fr References: <479F0664.2070706@exalead.com> <20080130123705.GA21900@pulp.rsise.anu.edu.au> <1201702034.9179.59.camel@flake.lan.gerd-stolpmann.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1201702034.9179.59.camel@flake.lan.gerd-stolpmann.de> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Miltered: at concorde with ID 47A08CC4.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; zacchiroli:01 zack: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 packagers:01 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? 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? Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ............... now what? zack@{upsilon.cc,cs.unibo.it,debian.org} -<%>- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ? /\ All one has to do is hit the (15:57:15) Bac: no, la demo scema \/ right keys at the right time