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.5 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 1B4EFBC6C for ; Wed, 26 Sep 2007 19:53:13 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAGs4+kbAXQInemdsb2JhbACOLwEBCQo X-IronPort-AV: E=Sophos;i="4.21,198,1188770400"; d="scan'208";a="1832377" Received: from concorde.inria.fr ([192.93.2.39]) by mail2-smtp-roc.national.inria.fr with ESMTP; 26 Sep 2007 19:53:12 +0200 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l8QHrCJ0028521 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Wed, 26 Sep 2007 19:53:12 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAGs4+kaACH6C/2dsb2JhbAA X-IronPort-AV: E=Sophos;i="4.21,198,1188770400"; d="scan'208";a="1531218" Received: from lb-nat-3.cs.umd.edu (HELO dispatch.cs.umd.edu) ([128.8.126.130]) by mail1-smtp-roc.national.inria.fr with ESMTP; 26 Sep 2007 19:53:11 +0200 Received: from [172.16.4.16] (bruce.cs.umd.edu [172.16.4.16]) by dispatch.cs.umd.edu (8.13.1/8.12.5) with ESMTP id l8QHr07s003175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 26 Sep 2007 13:53:02 -0400 Message-ID: <46FA9C97.9010003@cs.umd.edu> Date: Wed, 26 Sep 2007 13:53:27 -0400 From: Mike Furr User-Agent: Icedove 1.5.0.12 (X11/20070606) MIME-Version: 1.0 To: caml-list List Subject: Re: Cherry-picking modules (was Re: [Caml-list] [ANN] OCaml Reins 0.1 - Persistent Data Structure Library) 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> In-Reply-To: <1190826765.14453.34.camel@rosella.wigram> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-CSD-MailScanner-Information: Please email staff@cs.umd.edu for more information X-CSD-MailScanner: Found to be clean X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.399, required 5, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60) X-CSD-MailScanner-From: furr@cs.umd.edu X-Miltered: at concorde with ID 46FA9C88.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 ocaml:01 gcc:01 dependencies:01 gcc:01 statically:01 -mike:01 wrote:01 maintainer:01 compile:01 caml-list:01 surprising:01 data:02 modules:02 binary:02 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. > None of my clients will be needing this library to use it, > because they're not (using Felix as) Ocaml programmers. > > If I used it, it would be used ONCE by users to build the > Felix executable and discarded. Already, Python, Ocaml > and C++ are needed for this single build. 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). 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). > will your build scripts work on Windows? > Will Omakes and findlibs and Ounits build scripts build > transparently on Windows? I haven't tested it, but I would be very surprised if they didn't. > My build script do -- they're platform independent. > > [Yes, I know Omake is designed specifically to work on Windows > to enable platform independent builds] And I am relying on that fact. Good thing I didn't just cut and paste the relevant omake code to compile my stuff on linux. :-p -mike