From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 37EFCBC29 for ; Sat, 5 Aug 2006 02:36:48 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k750aliD016162 for ; Sat, 5 Aug 2006 02:36:47 +0200 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id CAA24892 for ; Sat, 5 Aug 2006 02:36:47 +0200 (MET DST) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by nez-perce.inria.fr (8.13.6/8.13.6) with ESMTP id k750aeon009393 for ; Sat, 5 Aug 2006 02:36:46 +0200 Received: from rosella (ppp30-178.lns1.syd2.internode.on.net [59.167.30.178] (may be forged)) by smtp1.adl2.internode.on.net (8.13.6/8.13.5) with ESMTP id k750aGAT062469; Sat, 5 Aug 2006 10:06:17 +0930 (CST) (envelope-from skaller@users.sourceforge.net) Subject: Re: [Caml-list] Re: ocaml support in autotools From: skaller To: Stefano Zacchiroli Cc: Inria Ocaml Mailing List In-Reply-To: <20060804124813.GC7146@aquarium.takhisis.invalid> References: <44CE2C74.4070607@inria.fr> <44CE6483.9070205@tepkom.ru> <44D1F265.4040401@inria.fr> <20060804044055.79801082.bga@tepkom.ru> <1154669546.5926.34.camel@rosella.wigram> <20060804124813.GC7146@aquarium.takhisis.invalid> Content-Type: text/plain Date: Sat, 05 Aug 2006 10:36:16 +1000 Message-Id: <1154738176.5926.89.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 44D3E81F.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 44D3E818.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocaml:01 zacchiroli:01 ocaml:01 packagers:01 packagers:01 cvs:01 bug:01 overkill:01 autoconf:01 config:01 kernels:01 compilation:01 compiler:01 2006:98 2006:98 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 On Fri, 2006-08-04 at 14:48 +0200, Stefano Zacchiroli wrote: > On Fri, Aug 04, 2006 at 03:32:26PM +1000, skaller wrote: > > BTW: anyone working on this should examine the Debian Ocaml Policy. > > Sorry no link off hand, ask on > > The policy is available on line at this URL: > > http://pkg-ocaml-maint.alioth.debian.org/ocaml_packaging_policy.html/index.html Thanks.. > > At least any macros should work well with Debian packagers > > requirements, people there have high expertise packaging Ocaml > > stuff. [] > Still, I don't see the relationship of the policy with ocaml autotools > support. I mention the policy document because it provides context which may help factor autotools macros/variables etc. There is a relationship: Debian packagers have to deal with people's build systems. > You may want to perform such a check at configure time, to ensure that > linking will succeed, but IMO it would be overkilling and not really > needed. After all the target user of autotools is a developer, not the > final user. That's fine when everything works.. the problem comes when something goes wrong. Then the person with the error is going to try all sorts of things to solve the problem .. using the latest cvs/svn repository version for example .. which typically only have the autotools original sources, not the generated scripts. Perhaps not on Debian or GODI .. but it is common for Ocaml programmers to get inconsistent libraries simply because there's no way to keep track of what libraries you have -- happens to me all the time when I upgrade (in fact, its a bug in the Ocaml install procedure itself .. it doesn't properly clean out the installation target) So maybe a trial link is overkill .. when it succeeds: it might be useful is it fails though. In any case, this kind of thing is precisely what configuration scripts actually do. Autoconf generated script regularly compiles, links, and even runs C programs .. and so does my Python hosted config script. For example we had some code failing and it turned out our test of Linux epoll was faulty. We just tried to compile a file using create_epoll() but that compiles and links on Linux 2.4 kernels.. it doesn't work though. You actually have to executed the function and check it doesn't return -1 to know if you have epoll support. Exactly how one would do this in a cross compilation environment I don't know (Felix is a cross-cross compiler). -- John Skaller Felix, successor to C++: http://felix.sf.net