[LLVMdev] GSoC Proposal: Language bindings via. SWIG

[Eric Jonas]

On Sat, 2008-03-29 at 08:15 +0530, Mahadevan R wrote:
> >  but I'd just like to point out that for python bindings at least, you
> >  can quite easily manipulate the LLVM infrastructure via ctypes as a
> >  shared object / dll -- no C required! Those of us interested in talking
> 
> ctypes brings with it it's own troubles. To use it in any non-trivial way,
> one must write enough non-trivial wrapper code in Python. Performance
> is also affected (though I haven't measured it myself).
> 

In my experience, even when combining two languages with fairly similar
object-orientation semantics like python and C++ , you always have to
write a decent chunk of glue code. When the semantics are wildly
different, the amount of glue code becomes non-trivial. The question
becomes, do you want to write your bindings in a language like C or in
your native language (which you ostensibly love more than C anyway, or
you probably wouldn't be creating the bindings in the first place). 

Even SWIG isn't a panacea, and still forces you to write a layer on top
of the resulting swig objects if you want an interface that looks
appropriate for your native language. 

> Boost.Python[1] is another option.
Boost.Python is an awesome tool for wrapping simple projects, and I've
used it in the past for four or five somewhat-complex object
hierarchies. We had many object lifecycle issues that ended up rendering
it unusable with our existing high-performance code (some numeric, some
network). Also, it does all manner of C++ template magic, and when it
breaks / fails to do what you want it too / changes in a subtle way
between boost revisions, god help you. 

> All said, it is not so difficult to write Python extensions in C (which
> probably is one reason so many glue tools exist?).

I'd argue that python's dog-slow performance in some areas ("Help me,
PyPy project, you're my only hope!") coupled with python coders
reluctance to touch C with a ten-foot pole also contributes to the
proliferation of these tools :) 

And of course, all I'm really arguing for here is for the LLVM build
process (Which, after an hour, I still don't understand) to build the
shared libraries correctly so that I can use it from lisp :) 

			...Eric