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 WAA24653; Tue, 18 May 2004 22:52:28 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 WAA24637 for ; Tue, 18 May 2004 22:52:27 +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.12.10/8.12.10) with ESMTP id i4IKqOEV000987 for ; Tue, 18 May 2004 22:52:25 +0200 Received: from [192.168.1.200] (ppp119-251.lns2.syd3.internode.on.net [150.101.119.251] (may be forged)) by smtp1.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i4IKqGZq048551; Wed, 19 May 2004 06:22:18 +0930 (CST) Subject: Re: [Caml-list] Automatic wrapper generator From: skaller Reply-To: skaller@users.sourceforge.net To: Richard Jones Cc: caml-list In-Reply-To: <20040518192708.GA29803@redhat.com> References: <1084869517.19838.409.camel@pelican.wigram> <20040518090635.GA6918@bourg.inria.fr> <1084875941.19838.446.camel@pelican.wigram> <20040518121147.GA20094@redhat.com> <1084905288.19838.661.camel@pelican.wigram> <20040518192708.GA29803@redhat.com> Content-Type: text/plain Message-Id: <1084913536.19838.688.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 19 May 2004 06:52:16 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 40AA7788.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 sourceforge:01 2004:99 forgets:01 annotations:01 generics:01 generic:01 pretend:01 abandoning:01 swig:01 hooks:01 constants:01 conforms:01 9660:01 glebe:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Wed, 2004-05-19 at 05:27, Richard Jones wrote: > I think your analysis is correct, except that you've missed out C > macros. Both the Perl and Gtk C interfaces use macros all over the > place as a kind of inline function. Flxcc currently forgets all about macros. I'm not totally unhappy :) You may have to call __f instead of f. That's not quite as bad as losing M_PI out of math.h though. To fix this I'd need a C preprocessor to modify, and probably also some annotations to help chose the macros to export as part of the interface. They'd have to be typed.. which isn't so easy if the macros are used as generics. Felix itself has no problem with binding macros, including generic ones (just cheat a bit and pretend they're really parametrically polymorphic). Note I haven't forgotten them. Indeed one of my main reasons for abandoning SWIG was that it doesn't provide any hooks to catch macros intended as functions. (It catches constants automatically though). The bottom line is that if you want to make a wrapper that conforms to a well specified (documented) interface, you should do it 'by hand' or by processing the documentation, not by processing the source code. Of course probably the fastest way to do this is to patch up a flxcc generated wrapper.. :) -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net ------------------- 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