[Xapian-devel] Available backends in xapian.h

[Olly Betts]

On Tue, May 10, 2005 at 01:42:25AM +0200, Francesco Garosi wrote:
> It looks like the new entries in xapian-bindings/configure.ac work, except
> for a little glitch at line 144: I think it should read
> 
> 	    PYTHON_LIBS="`$PYTHON -c 'import os,sys;print "-L" + os.path.join(sys.prefix,"libs").replace(os.sep,"/"),"-lpython"+sys.version[[:3]].replace(".","")'`"
> ;;
> 
> (ie. doubling the square brackets).

Oops, yes.  I copied the line out to test it in the shell and had to
undouble the square brackets, then forgot to redouble them.  I always
seem to make that mistake.

> I also used "+" instead of "," for the -L parameter, but it shouldn't
> be necessary, it just makes the output more similar to others.

You're right - that wasn't deliberate.

> However in my opinion the reference to cygwin should
> be removed: cygwin ships with its own Python (guess what, in that version
> os.pathsep is actually ":"! ;-) ), and this could confuse the toolchain.

OK.  Any idea about pw32?  I just copied the "recognise windows"
criterion from libtool...

> I also added more double quotes in xapian-bindings/python/Makefile.am, namely
> at line 44: probably this escaped inadvertently your attention... so it
> should read:
> 
> 	PYTHONPATH=".$(PYTHON_PATHSEP).libs" $(PYTHON) -c "import xapian"

Good catch.

> One only last (possible?) glitch: in xapian-core/configure.ac:690 I had
> to force the suppression of a warning with -Wno-unused (wasn't it there
> before?), as in queryparser.lemony:465 I get a "warning: unused parameter
> 'state'". I don't think you want to change the function definition

Actually, I do.  I changed QueryParser to no longer store a list of
terms internally (since you can get the same list by asking the Query
object returned) but I didn't clean up the state parameter which is now
unused.  And my development tree is current configured with GCC 2.95
so -Werror isn't on and I missed the new warning.

> After these changes I re-bootstrapped the SVN distribution and built xapian-core
> and xapian-bindings. I still have some small problems with xapian-applications
> (although Omega builds fine), but they are probably unrelated to these updates.

What're the problems?

> >Adding 'xapian-config --libdir' may be the answer, but we need to decide
> >if it should report "where the library is now" or "where the library is
> >or will be installed".
> 
> I think that it could depend on which xapian-config is invoked... for instance,
> as you do for other things just there (referring to xapian-config.in):
> 
> 	# check if this is an uninstalled xapian-config
> 	if test -n "$builddir" -a -f "${builddir}Makefile" ; then
> 	    libs="@abs_builddir@/.libs"
> 	else
> 	    libs="@libdir@"
> 	fi
>     echo "$libs"

But here we also want the directory where the libraries are now, because
then we can link against them.  We can then install the binary we've
linked against those libraries and the libraries themselves and the
dynamic linker will handle this.

But for --libdir, this may not work.  I could use the result of
xapian-config --libdir to build a wrapper script which sets PATH and
runs my application like so:

echo "#!/bin/sh" > wrapper.sh
echo PATH="$PATH;`xapian-config --libdir`" >> wrapper.sh
echo "exec myapp" >> wrapper.sh

Then I actually want where the library will be when the application is
run.  Which makes the installed location the answer I really want, even
if xapian-core hasn't yet been installed.

Cheers,
    Olly