[Xapian-devel] Error handling in the bindings

[Richard Boulton]

Olly Betts wrote:
> 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.

That's a good idea - I'll check the code shortly.

> 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".

Ah - I wasn't thinking of it that way - I was thinking of "language 
independent" versus "language specific".  Possibly I named the directory 
badly; I was thinking it would be a sensible target to remove all the 
language specific #ifdefs and the like from xapian.i, and put them into 
the language specific directories.  This doesn't need xapian.i to be in 
a subdirectory though, so I'll move it back. ;-)  Perhaps I should 
rename the swig directory to "generic" or something like that.  (As well 
as xapian.i, it contains a generic implementation of except.i for those 
languages which don't need special handling, and I'm expecting there 
will be other similar code added to it at some point too.)

> 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.

Good point, that's a good target to aim for.  So, in the end, that would 
leave a xapian.i which simply included a few fix ups, and then included 
all the relevant C++ header files.  Which would be much nicer.

> 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.

I'll stick to Perl then; I'll just have to get my head around it again.

> 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.

I tried the "install and add an option to xapian-config" option, and it 
works okay, but I'm unhappy with installing a file which is really part 
of the build system, so I'll just stick to the "relative to srcdir" 
option for now.  I expect it will work for all current maintainer 
builds, since bootstrap.sh requires that layout too (as does the MSVC 
build).

-- 
Richard