A short note: this message comes as a public reply to a discussion about
xapian-bindings, that is why it can look a little bit incomplete... however
the problem for now was to modify the xapian-core distribution so that there
are symbols #defined (or maybe #undefined) to reflect what backends were
available in the library.
As I said to Olly, I'm a complete newbie at Autotools (and SWIG), so my
approach can look naive. However it's only a proposal: there are surely
better solutions.
I tried the following:
- changed $(srcdir)/include/xapian.h into $(srcdir)/include/xapian.h.in
- added the following lines somewhere (namely, line 51) in xapian.h.in:
---8-<-------------
// Backends
#define XAPIAN_BACKEND_MUSCAT36
#define XAPIAN_BACKEND_QUARTZ
#define XAPIAN_BACKEND_INMEMORY
#define XAPIAN_BACKEND_REMOTE
---8-<-------------
- added the following to configure.ac, at line 374 (to have $build_* set):
---8-<-------------
dnl @@MODIFIED@@ - Franz
dnl Remove unsupported backend #defines from xapian.h.in and output xapian.h
AC_MSG_CHECKING([for backends to exclude in xapian.h])
desc_excluded_backends=""
excluded_backends="\\#define XAPIAN_BACKEND_\(DUMMY"
if test false = "$build_muscat36"; then
excluded_backends="$excluded_backends\|MUSCAT36"
desc_excluded_backends="$desc_excluded_backends Muscat36"
fi
if test false = "$build_quartz"; then
excluded_backends="$excluded_backends\|QUARTZ"
desc_excluded_backends="$desc_excluded_backends Quartz"
fi
if test false = "$build_inmemory"; then
excluded_backends="$excluded_backends\|INMEMORY"
desc_excluded_backends="$desc_excluded_backends InMemory"
fi
if test false = "$build_remote"; then
excluded_backends="$excluded_backends\|REMOTE"
desc_excluded_backends="$desc_excluded_backends Remote"
fi
excluded_backends="$excluded_backends\)"
if test x"" = x"$desc_excluded_backends"; then
desc_excluded_backends="none"
fi
grep -v "$excluded_backends" "$srcdir/include/xapian.h.in"
> "$srcdir/include/xapian.h"
2> /dev/null
dnl The "grep" line is obviously just one
AC_MSG_RESULT($desc_excluded_backends)
dnl @@MODIFIED@@ - ends
---8-<-------------
- done an autoreconf and a configure: Muscat36 was reported to be dropped
In fact the resulting xapian.h only defines XAPIAN_BACKEND_QUARTZ,
XAPIAN_BACKEND_INMEMORY
and XAPIAN_BACKEND_REMOTE, and the configure script reports the following
line "somewhere":
checking for backends to exclude in xapian.h... Muscat36
as expected. Apart from being (once again) a "brute force" type of
procedure,
I think that it has another drawback: it moves the generation of a source
file (other than config.h) into the configure step. I don't know if this
is correct. However, while there are no other solutions, this could do the
job. At least it does not imply the use of exoteric rules in Makefile.in
(and thus something I can't even think of in Makefile.am).
I really hope this would help somehow.
Cheers,
F.
On Thu, Apr 28, 2005 at 07:57:25PM +0200, franz.g at tin.it wrote:> I think that it has another drawback: it moves the generation of a source > file (other than config.h) into the configure step. I don't know if this > is correct.We also already generate include/xapian/version.h from configure. But no need to worry about working on this - I checked in changes to do this last night! I've put the defines into version.h rather than generate yet more files. I've nearly got the SWIG side working too, based on your previous patch. I was going to mail you once that was checked in, but it was taking ages to rebuild and then I got distracted... Sorry about the duplicated effort. Cheers, Olly
Hi Olly, I tried several times and with different configurations to build on Windows some of the bindings from the SVN repository. I had to use the latest (release candidate) tools from MinGW, because the stable ones are far out of date. 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. 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; 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!). 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). 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). 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 and which causes the "shared object" (a DLL here) not to be generated: the .libs directory only contains xapian.a, xapian.la, xapian.lai and xapian_wrap.o: no .dll (or .so). Exactly the same happens for Python. 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. Sorry for the lack of conciseness and cheers, F.