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 EAA04665; Sun, 25 Apr 2004 04:57:00 +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 EAA04718 for ; Sun, 25 Apr 2004 04:56:59 +0200 (MET DST) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i3P2uuYM026735 for ; Sun, 25 Apr 2004 04:56:57 +0200 Received: from [192.168.1.200] (ppp119-113.lns1.syd2.internode.on.net [150.101.119.113]) by smtp3.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i3P2ukk2082040; Sun, 25 Apr 2004 12:26:47 +0930 (CST) Subject: Re: [Caml-list] swig like library... From: skaller Reply-To: skaller@users.sourceforge.net To: art yerkes Cc: vanevery@indiegamedesign.com, caml-list In-Reply-To: <20040424202443.05043abc.ayerkes@speakeasy.net> References: <1082837516.9537.114.camel@pelican.wigram> <20040424202443.05043abc.ayerkes@speakeasy.net> Content-Type: text/plain Message-Id: <1082861805.9537.240.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 25 Apr 2004 12:56:46 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at concorde by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 swig:01 sourceforge:01 2004:99 yerkes:01 2004:99 sourceforge:01 brandon:99 swig:01 wrappers:01 debugging:01 'add:01 on':99 delves:01 bottleneck:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sun, 2004-04-25 at 11:24, art yerkes wrote: > On 25 Apr 2004 06:11:56 +1000 > skaller wrote: > > > On Sun, 2004-04-25 at 03:12, Brandon J. Van Every wrote: > > > skaller wrote: > > > > > > > > However SWIG isn't very satisfactory.. I'm thinking of > > > > writing an Ocaml program for building wrappers. > > > > > > What is so unsatisfactory about SWIG that you would start a new effort > > > and avoid improving SWIG? > > SWIG has been burned before by adding too many languages too quickly. Yes, I think it is bloated. I discussed inclusion of my module with David and suggested a dynamic loading solution would be an option I would find acceptable, and he prefered this option: I have no problem with that, Felix *is* a new language. I submitted a patch. But he didn't incorporate it. I think the whole system should be reorganised so the core SWIG builds independently of ANY language module (except perhaps an XML or debugging output module), and each language module should be an independent 'add on' in a separate CVS module. This reorganisation would be more work. But just adding dynamic loading would have taken about 1/2 an hour. > I do agree that dynamic loading would partially solve this problem, > by allowing modules to be pulled out into separate projects. So does David .. so why doesn't he just apply my patch? > SWIG isn't strictly *for C*, it's for standard C++ and is not designed > to accept core C headers or GNU extensions (this is part of why it works > with incomplete type information, and missing includes). It's assumed > that the language SWIG will process for already has a standard library, > even if it's not specifically stated. Unfortunately that isn't correct. SWIG has an option to follow all includes.. and it stupidly delves into system headers when it does. Without this option, you can't follow nested includes that you DO need to follow to get enough information: quite a few GNU headers just #include other ones (eg gtk.h). The workaround of including things manually is a pain, and only works for one level .. I could fix this easily. If I had CVS access.. > I agree that the lack of further automation is a bottleneck for SWIG > users. Most SWIG users don't seem to care: they have to make typemaps and things anyhow, so they can always just write out the interfaces by hand: that still saves a HEAP of work compared to hand writing the wrappers for an Ocaml or Python binding. However there are some of us that need to process larger headers 'as is' without being able to modify them, and where it is impractical to assume they're stable and so can't be copied: for some people because they're wrapping 'in development' libraries, and others, such as me, because the wrapper annotations have to work on a large number of distinct platforms. > I have considered forking some of the core type functions into the > ocaml module for that reason. That's basically what I did. But I can't hook everything I need to: some libraries, for example gmp, provide 'convenience' macros I can't see precisely because they're macros. I also depend on 'details of the implementation' that could be changed at any time. In other cases it is frustrating: I have developed a technique for automating callback handling, which is something useful to all language users, and am unable to share the technology -- sharing is useful to me for the usual reason: user feedback improves quality, and also makes me feel good contributing something useful :) The bottom line is: I can't distribute wrapper generation technology for Felix at the moment without redistributing a copy of SWIG. Which is a not an acceptable solution. -- 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