[Xapian-devel] Error handling in the bindings

[Richard Boulton]

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

Correct.  Done.

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

Oh, right.  Thanks for the hint.  I've called it generic/generic.mk for now.

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

I've got no problem with that - I hadn't even got as far as thinking 
about making the language stuff use non-recursive make.

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

Correct.

-- 
Richard