From: Ben Gamari <bgamari@gmail.com>
To: notmuch <notmuch@notmuchmail.org>
Subject: Re: SWIG (and particularly Python) bindings
Date: Wed, 30 Dec 2009 11:10:31 -0500 [thread overview]
Message-ID: <1262188858-sup-2372@ben-laptop> (raw)
In-Reply-To: <20091230115223.1b3472a1@hikari>
Excerpts from Adrian Perez de Castro's message of Wed Dec 30 05:52:23 -0500 2009:
> On Tue, 29 Dec 2009 04:16:43 -0500, Ben wrote:
>
> > Regardless, I thought it might be nice to have access to the notmuch
> > backend from a language other than C (preferably my high-level language
> > of choice, python) [...]
>
> Funny, I was just doing the same: a Python binding. Haha, so now we have
> two just-backed Python bindings. What should we do?
Heh, it's a small world, eh?
>
> > [...] To this end, I took a few hours today acquainting
> > myself with SWIG and produced these bindings for Python. Unfortunately,
> > it doesn't appear that SWIG has particularly good support for
> > object-oriented C [...]
>
> I already used SWIG sometimes in the past (and did not like it a lot), so
> my binding is using Cython [*] (which is exactly like Pyrex plus some extra
> features), so the binding is partly manual.
>
I liked that SWIG would give us coverage for a multitude of languages
with little work. Unfortunately, getting an object oriented interface
requires wrapping the functions exposed by SWIG. Nevertheless, I think
being able to generically hide the ugliness of the binding glue itself
is quite nice. Moveover, there's effectively no SWIG interface code to
maintain. It's literally just a [#%]include "notmuch.h". The rest is
all the Python wrapper. This seems like a nice binding model, short of
SWIG doing everything (the developers at some point might add support
for proper wrapping of object-oriented C code).
> > While the bindings are currently in the form of a patch to notmuch
> > (creating a top-level swig directory in the source tree), they could
> > certainly be moved out-of-tree if the powers that be don't feel it
> > appropriate to include them. [...]
>
> Same here, see attached patch. It is currently unfinished, and I was just
> about to add support for iterating notmuch_threads_t and other similar
> structures. I can also publish a Git repo with the entire branch, just
> drop me a line if you want me to do that.
>
In my approach, I just used the iterator protocol.
> > [...] Unfortunately, the build system is currently almost entirely
> > independent from the notmuch build system. If these are to be
> > included in-tree, I would be curious to hear people have
> > to say about how we might integrate it into the sup build system.
> ^^^
> (Mmmh, I suppose you mean "notmuch build system" there :P)
Heh, yep.
>
> Mine is a little more cooked, as I have added a distutils "setup.py"
> script. The bad news is that Python modules need to be compiled as
> relocatable object files (-fPIC to teh rescue!), and the linker will
> refuse to link the generated code with "notmuch.a" -- so I am instructing
> distutils to compile *all* sources again. Not nice.
>
In my patch I simple I modified the LDFLAGS to include -fPIC. Not sure if
that's an acceptable option or not.
> BTW, I think that if more bindings start to appear, Notmuch might be built
> as a shared library, to avoid duplicating it everywhere. One option may be
> using *just* libtool but not the rest of auto-foo tools (for the record:
> I agree with Carl that they are slow and wicked).
>
I think you're probably right. Libtool is probably the best option here
(Despite the fact that I, too, have a bitter hatred of autotools).
Cheers,
- Ben
next prev parent reply other threads:[~2009-12-30 16:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-29 9:16 SWIG (and particularly Python) bindings Ben Gamari
2009-12-30 10:52 ` Adrian Perez de Castro
2009-12-30 11:34 ` Scott Robinson
2010-01-16 4:09 ` Ben Gamari
2010-01-16 4:28 ` [PATCH] libtoolize notmuch Ben Gamari
2010-01-20 8:51 ` Carl Worth
2009-12-30 16:10 ` Ben Gamari [this message]
2010-01-20 8:48 ` SWIG (and particularly Python) bindings Carl Worth
2010-01-20 8:45 ` Carl Worth
2010-01-20 18:39 ` Ben Gamari
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://notmuchmail.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1262188858-sup-2372@ben-laptop \
--to=bgamari@gmail.com \
--cc=notmuch@notmuchmail.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://yhetil.org/notmuch.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).