[Xapian-devel] Error handling in the bindings

[Olly Betts]

On Fri, Mar 09, 2007 at 11:04:24AM +0000, Richard Boulton wrote:
> 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.)

I'd probably suggest moving everything in swig up a level, so
"swig/defaults" would just be "generic", instead of "generic/defaults",
which is perhaps that's what you had in mind anyway.

It might be better if the Makefile.am fragment wasn't "Makefile.mk" -
I've used the convention in the xapian-core tree that "Makefile.mk" is a
non-recursive replacement for a subdirectory's "Makefile.am", while
"Makefile.am" fragments are "<somethingelse>.mk" (e.g. "docsource.mk"),
which I think is a useful distinction to make.  Sorry, I really should
document such things - I'll add a note to HACKING when I get a chance.

Incidentally, I think we should keep the language directories as
recursively made, at least for now - otherwise if you're working on a
particular language and tweaking xapian.i, you'd have to wait for it to
rebuild all the languages which takes a while.  Once all the language
specific stuff is split out and we're using the headers for the class
definitions, xapian.i should be a tiny stub which rarely changes, and
this shouldn't be a problem.

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

Exactly.  We might need the odd bit of macro magic in the headers
(there's already one bit to handle GCC's visibility support, though
that's temporary and can go once we sort out visibility support in
xapian-core itself).  That's not ideal but better than having to
maintain two copies of essentially the same information.

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

Yeah, I came to the same conclusion here when thinking about the options.
This is where the "xapian-bindings is just like any other user of the
Xapian API" plan doesn't fit particularly well.

If the file is small, putting it in the xapian-config script as a HERE
document at least eliminates the extra file, though we're still
installing information which is part of the build system.  We have the
thin end of that wedge already though - "xapian-config --swigflags"!

> I expect it will work for all current maintainer 
> builds, since bootstrap.sh requires that layout too (as does the MSVC 
> build).

Presumably we'll ship the files that are generated, so this is at least
only a concern if you want to do development on the bindings themselves?

Cheers,
    Olly