[Xapian-devel] Error handling in the bindings

[Olly Betts]

On Thu, Mar 08, 2007 at 05:11:17PM +0000, Richard Boulton wrote:
> Coming back to this topic - as you may have seen, I've committed to 
> xapian-bindings some changes which reorganise the SWIG source files so 
> that we can add language specific exception handling just by adding an 
> "except.i" file to the source directory for the language in question - a 
> default except.i file is used if this isn't present.  I've split the TCL 
> exception handling and PHP exception handling into except.i files, 
> because they were already significantly customised (with #ifdefs, and 
> similar), but haven't yet committed anything which changes behaviour (as 
> far as I can tell).

I've not looked in detail, but it does sound like an improvement.

I think it might be useful at this point to compare the code (C++ and
scripting language) generated now with that generated before your
recent changes.  The bindings testsuite isn't as complete as I'd
like, so it would be good to have confidence that this doesn't introduce
any problems.  I recall some subtle issues with SWIG-time versus compile
time preprocessing which took me a while to sort out with PHP, for
example.

I have a reasonably strong preference for keeping xapian.i at the top
level though.  It used to be in a "swig" subdirectory several years ago
and I deliberately moved it out because I found it easy to work with
that way!  So reversing that change is a retrograde step for me I'm
afraid.

All the bindings in xapian-bindings are SWIG-based except Java, which
will move over when I (or someone else!) gets round to it, so I don't
think we need to worry about separating "swig" from "non-swig".

Something to bear in mind while refactoring is that it would be nice
to be able to just use the Xapian headers themselves rather than
reproducing all the class structures in xapian.i.  Over time I've
found several small mistakes in the copied version, and it requires
us to remember to copy over new classes and methods or they don't
get wrapped.  We should be able to feed SWIG all the %ignore, %rename,
%extend, etc first.

> I have several questions:
> 
> 1. Is it okay to require Python for maintainer mode builds of Xapian-core?

I don't see it as a huge problem if there's a good reason for it, but
it's also good to keep the list of prerequisites under control, and I
don't see a particularly compelling case here.

If you're on Linux or FreeBSD or similar it's OK since chances are
you'll have both installed already, but vendor Unix flavours often
don't.  The sourceforge compile farm had perl everywhere but not
python, for example.

So I think it's probably best to just stick to Perl for now.

> 2. Is it okay to replace the Perl generate-exceptions.in with my Python one?

I prefer Perl to Python for these sort of text manipulation tasks, and
we're using Perl for several other scripts.  The diff between Perl and
Python version makes it a bit hard to judge, but it seemed clearer to my
eyes in Perl.

I wouldn't worry about rusty Perl - it just needs to do the job.  It
doesn't matter if it's not "idiomatic" or as efficient as possible.

> 3. How best should I include exception_data.py from the xapian-bindings 
> module.  My current thinking is to assume that the sources are laid out 
> as assumed by bootstrap.sh if a maintainer mode build is in progress, 
> and to look for exception_data.py in "$srcdir/../xapian-core/", but I'd 
> like a better plan.  Perhaps I could add exception_data.py to the list 
> of installed files (going in $prefix/share/xapian/ perhaps), and add an 
> option to xapian-config.py which reported the directory it was installed in.

I don't have a magic answer for this - all the approaches seem to have
drawbacks.  I'd suggest sticking with "relative to srcdir" for now since
you've implemented it.  This should be fairly orthogonal to the rest, so
we can replace it if/when we have a better plan.

Cheers,
    Olly