[Xapian-devel] Available backends in xapian.h

[Olly Betts]

On Wed, May 04, 2005 at 01:57:27AM +0200, franz.g at tin.it wrote:
> Moreover, it's impossible to bootstrap Xapian (xapian-core too) directly
> on Windows: the latest unstable automake is 1.8.2 and Xapian requires at
> least 1.8.5; however this should not be a problem since stable releases
> do not require a bootstrap.

That's annoying.  While 1.8.5 isn't an absolute requirement, some of the
fixes between 1.8.2 and 1.8.5 look useful to us.  At least as you say
the Xapian releases are already bootstrapped (and so are snapshots so
this only bites those building directly from SVN).  Can automake 1.8.5
be installed from source?

> There is also a thing I could not understand: is SWIG 1.3.22 a mandatory
> requirement for xapian-bindings? The configure script fails when it finds
> SWIG 1.3.24

To bootstrap xapian-bindings, you need *BOTH* 1.3.22 *AND* 1.3.24.  If
you install SWIG 1.3.22's swig executables as swig-1.3.22 then configure
will pick it up by itself.

The problem is that changes to the generic parts of SWIG 1.3.23 broke
the code generated by the PHP backend.  And since SWIG effectively
doesn't have a PHP maintainer these days (Sam used to be, but he's
been way too busy with work for ages) it doesn't look like this is
likely to get fixed anytime soon.

Meanwhile, for C# we need SWIG 1.3.23 to support optional parameters.

This is all far from ideal, but there's not an easy solution I can see.

> this is only required for --enable-maintainer-mode anyway,
> so it generally falls into the same case as above (the option also breaks
> xapian-core builds actually, as it passes -Werror and there are many header
> files that generate warnings!).

Which GCC version?  Warnings from system headers are normally suppressed
(at least by GCC 3 onwards).  And configure doesn't enabled -Werror for
GCC < 3.0 because GCC 2.95 generates spurious warnings for a particular
C++ construct we use quite a bit.

I can easily disable the automatic switching on of -Werror on windows,
but it'd be useful to document exactly what we hit which what required
it in case we want to readjust the criteria later.

> But there are real problems that, in my opinion, are very difficult to
> override.  Some are due to the oddness of the Windows platforms, like
> the use of backslashes as a delimiter and semicolons to include
> multiple directories in path environment variables (like PATH,
> LD_LIBRARY_PATH and so on).

The colons vs. semicolons in PATH, etc can be easily addressed by using
the autoconf supplied $(PATH_SEPARATOR) instead.

Backslash is more difficult, but much of Windows can cope with / instead
so there's still hope.

> Also, Win32 directory setup for Python is quite different than for
> UNIX in the official distribution (no pythonX.Y subdirectories in the
> standard include and library path).

OK, and your setup.py took that into account presumably?

> I also tried to build bindings for tcl8, which comes with MSYS and has a
> more usual setup, from the UNIX point of view. But this also fails, because
> of this problem (which also appears at link time in other bindings):
> 
> /bin/sh ../libtool --mode=link --tag=CXX g++ -Wall -Wno-unused -Wno-uninitialized
> -g -O2 -IC:/Projects/MANAGED/BLEEDING_EDGE/INST/include   -o xapian.la -rpath
> C:/Development/mingw-3.1/lib/tcl8.4/../xapian0.8.5.1 -avoid-version -module
> xapian_wrap.lo -Wl,--enable-runtime-pseudo-reloc C:/Projects/MANAGED/BLEEDING_EDGE/INST/lib/libxapian.la
> 
> libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32
> shared libraries

OK, this is a standard libtool win32 gotcha.  You need to add
-no-undefined to xapian_la_LDFLAGS in tcl8/Makefile.am.

> I don't know if it's worth the effort to investigate for a way to include
> Win32 in the supported platforms, although I'll try to continue to. However
> the "setup.py" method is usually the preferred one for Python, and it can
> probably be considered quite robust. The script I sent is not very elaborate,
> but it can be modified to ensure that the module builds without problems
> on all supported platforms - possibly invoking xapian-config.

I think it's probably worthwhile.  People are likely to want to use the
bindings on all platforms which Xapian itself can be built on.

I've commited fixes for passing -no-undefined and using $(PATH_SEPARATOR)
instead of ':' (except when running java - I'm not sure what's correct
there).  So you should be able to get a bit further if you "svn update".

I'll take another quick look at the setup.py you sent before, but I may
decide to leave that until after the 0.9.0 release which I don't want to
delay further if I can avoid it.

Cheers,
    Olly