Re: [Caml-list] swig like library...

[skaller <skaller@users.sourceforge.net>]

On Sun, 2004-04-25 at 11:24, art yerkes wrote:
> On 25 Apr 2004 06:11:56 +1000
> skaller <skaller@users.sourceforge.net> 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