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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 94D8CBC69 for ; Wed, 26 Sep 2007 21:16:47 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAABtM+kbLENaMnmdsb2JhbACOMAEBAQEHBAYFChg X-IronPort-AV: E=Sophos;i="4.21,198,1188770400"; d="scan'208";a="3296555" Received: from concorde.inria.fr ([192.93.2.39]) by mail3-smtp-sop.national.inria.fr with ESMTP; 26 Sep 2007 21:16:46 +0200 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l8QJGkUd001465 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Wed, 26 Sep 2007 21:16:47 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAABtM+kbLENaMnmdsb2JhbACOMAEBAQEHBAYFChg X-IronPort-AV: E=Sophos;i="4.21,198,1188770400"; d="scan'208";a="3296554" Received: from ipmail01.adl2.internode.on.net ([203.16.214.140]) by mail3-smtp-sop.national.inria.fr with ESMTP; 26 Sep 2007 21:16:44 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAALJK+kZ5LHvc/2dsb2JhbAAM X-IronPort-AV: E=Sophos;i="4.21,198,1188743400"; d="scan'208";a="198205266" Received: from ppp121-44-123-220.lns10.syd6.internode.on.net (HELO [192.168.1.201]) ([121.44.123.220]) by ipmail01.adl2.internode.on.net with ESMTP; 27 Sep 2007 04:46:42 +0930 Subject: Re: Cherry-picking modules (was Re: [Caml-list] [ANN] OCaml Reins 0.1 - Persistent Data Structure Library) From: skaller To: Mike Furr Cc: caml-list List In-Reply-To: <46FA9C97.9010003@cs.umd.edu> References: <46F95938.7030107@cs.umd.edu> <17487E59-04F2-4509-87B5-24377B051E9E@epfl.ch> <46F961E5.5060302@cs.umd.edu> <55A4E82E-3D05-4F79-A8A6-A87905EB4FC8@epfl.ch> <1190787575.6800.21.camel@rosella.wigram> <1190826765.14453.34.camel@rosella.wigram> <46FA9C97.9010003@cs.umd.edu> Content-Type: text/plain Date: Thu, 27 Sep 2007 05:16:41 +1000 Message-Id: <1190834201.5998.19.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 46FAB01E.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 caching:01 gcc:01 dependencies:01 gcc:01 ocaml:01 distros:01 distro:01 statically:01 plagued:98 suck:98 sourceforge:01 imho:01 imho:01 wrote:01 On Wed, 2007-09-26 at 13:53 -0400, Mike Furr wrote: > skaller wrote: > > > This is true .. but you're missing something, which is slightly > > surprising considering you're the maintainer and DD manager > > of the Debian package for Felix .. > > I believe the main point here is that you are bending what I consider > best practice for felix because it is still in development and you want > to speed its adoption. I do understand that. Actually no: IMHO 'best practice' is that programs are *source code* and that is the only way they should be distributed. Binaries should never be installed or distributed: they're just a 'cache' and should be invisible. Felix is designed to work that way: you execute script directly, the same as Perl and Python. Other systems, such as C, are so utterly plagued by design faults and portability issues that systems like Debian were designed to do this caching in a reliable way and distribute the binaries .. but this is simply a consequence of the poor engineering of C. > You should no more expect them to build the reins library then for the > gcc authors should expect you to build all of the dependencies of > gcc/g++ (of which there appear to be >40 in the debian/control file for > that package). But that's because it is written in C. For Ocaml code I expect .. and indeed demand .. to build from source. That is possible because of the superior design of the Ocaml programming language. That is how Godi manages things -- and there's a good argument Debian Ocaml 'binary' packages should ACTUALLY contain source code which is built on demand: it would be a whole lot more portable and easier to maintain, since upgrades to Ocaml require modifying ALL the dang binary libraries, but very rarely any change to sources. Binary distros suck because user code not part of the distro isn't handled. 'Execute source' is the way to go, because it rebuilds everything, including user code, automatically as required. IMHO of course :) > When you distribute the felix binary, all of its ocaml > libraries are statically linked in, so they don't have to download > anything outside of your binary (which is the downside of your choice to > do source releases). Yes, this is true, however I don't own a compile farm to build all the binaries. -- John Skaller Felix, successor to C++: http://felix.sf.net