From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id HAA16508; Tue, 15 Oct 2002 07:25:43 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id HAA09570 for ; Tue, 15 Oct 2002 07:25:42 +0200 (MET DST) Received: from relay.pair.com (relay1.pair.com [209.68.1.20]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g9F5Pf512885 for ; Tue, 15 Oct 2002 07:25:41 +0200 (MET DST) Received: (qmail 32630 invoked from network); 15 Oct 2002 05:25:39 -0000 Received: from adsl-host-sf-228.apexworld.net (HELO checkerlap.d6.com) (66.114.212.228) by relay1.pair.com with SMTP; 15 Oct 2002 05:25:39 -0000 X-pair-Authenticated: 66.114.212.228 Message-Id: <4.3.2.7.2.20021014221300.0342f218@mail.d6.com> X-Sender: checker@mail.d6.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 14 Oct 2002 22:25:51 -0700 To: Sven LUTHER From: Chris Hecker Subject: Re: [Caml-list] CDK with Ocaml 3.06 (fwd) Cc: Sven LUTHER , Gerd Stolpmann , Pierre Weis , caml-list@inria.fr In-Reply-To: <20021015051532.GB2224@iliana> References: <4.3.2.7.2.20021014214720.0320a448@mail.d6.com> <20021014224457.GM1002@ice.gerd-stolpmann.de> <20021014181602.GA2620@iliana> <200210142038.WAA05623@pauillac.inria.fr> <20021014210719.GA3682@iliana> <20021014224457.GM1002@ice.gerd-stolpmann.de> <4.3.2.7.2.20021014214720.0320a448@mail.d6.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk >Yes, that would be a good start, windows binaries and bytecode. Yep, I think the right thing to do at the start would be to support windows binaries, bytecode for those libraries that don't need external C code libraries, and "opaque" source tarballs (by opaque, I mean the package manager will fetch the source code tarball just like it will fetch the binaries (and all the dependencies), but it won't attempt to build it or make it work). This would get the right stuff onto your machine, which is a start. Then we publish some guidelines and slowly the source becomes more and more consistent as people update, and then maybe we can solve the compilation problem. But at least we'll have started. >The outside dependencies (the ones on things not ocaml related, tcl/tk, >gtk+ and so on) is the main difficulty here. Yes. We just punt that problem for now. >But the -pack option is not yet standardized, and not used in much >cases, it seems to me. It's brand new, so give it time (and we need to get it working on windows, but that's close to solved now). Is there a problem with it that you're implying, or just that it hasn't taken off yet? > > Of course, if something like apt would just work for us (on all platforms, > > source and binary), then that would be excellent and we should just start > > using it. >it will never just work, it 'just works' on debian, because of the >debian maintainers who do the work of making sure the packages work. No, I just meant could we use the apt executable and data formats and not have to write any code that fetches files or checks dependencies and whatnot? In other words, would it save time to try to use it, or is it totally hard-coded to debian? >I don't have time to work on this though :((( Me neither, at least not for a year. Chris ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners