[Xapian-devel] Available backends in xapian.h

[franz.g at tin.it]

Hi Olly (and all),

you wrote:

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

Yes, it can be installed from the source distribution. I installed automake
1.9.5 (but still didn't try to bootstrap with that). However I think that
most users will try to pick up an already bootstrapped version.

And... 

>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 use gcc 3.4.2, but I think that there are some header files that gcc still
does not consider as system headers: an example is "Python.h" (probably
many source files include it using double quotes instead of angle brackets:
the Python manual is quite generic about this as in the same release of
Python documentation both forms are used). In my MinGW installation there
are some other warnings occurring in builds of xapian-core, I'll report
them if you think they are useful.

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

You're right, however the problem does not just reside in what the Xapian
build system passes to the appropriate tools, it arises instead when the
configuration scripts investigate for some paths, especially when there
is an official distribution for some supported scripting languages. For
instance, the Python prefix is reported to be something like "C:\Path\To\Python"
and this becomes "C:PathToPython" in the Makefile; I suppose that other
frameworks (like PHP that is probably even more used on Win32) may suffer
of the same problem. On the other hand, both interpreters as well as all
tools compiled with MinGW, understand better slashes than backslashes. But
for the other problems, I think that one viable solution is to make Win32/MinGW
a special case.

There is more however: for MinGW/MSYS the path separator is a colon (as
in UNIX), but for Python, $PYTHONPATH must have semicolons on Win32. If
you say you're not sure about java... well, then I tend to think that the
worst case is ours! This is what I mean when I say "oddness".

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

The "distutils" way takes everything in account, as AFAICS it makes a special
case of almost everything! In fact last night I was trying to see if there
is a way to use a dummy C module to extract compiler and linker parameters
at configuration time. But this was mostly for the usual Win32 problem you
were reporting. Of course using distutils implies that the script itself
has to be as portable as possible: I agree that mine was definitely not.
If the problem is just a compiler and/or linker switch, then it's definitely
better to use the Makefile. However this does not immediately solve the
problem of "pythonX.Y subdirectories": for that, probably, the special case
approach can also be a solution, as the official Python Win32 distribution
has a quite strict directory setup, and I hope it is almost the same for
at least the most popular distribution. There is an official distribution
for PHP for Win32 as well. For instance, Tcl/Tk can generate some ambiguities:
there is also an official Win32 package, but I guess there are many MinGW/MSYS
users out there that installed the package from the MSYS distribution. Probably
the latter would be the one that configuration scripts will consider first.
To break ambiguity, many variables can be decided after sourcing tclConfig.sh
(and tkConfig.sh), that are part of the distribution: the user could possibly
choose a path to tclConfig.sh in the configuration step.

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

You did, as your subsequent message shows. Maybe Win32 problems should not
delay the release of Xapian 0.9.0: after all, the core builds fine (apart
from the Remote backend) as it did with 0.8.5. The only thing I hope is
that all these modifications aimed at giving better Win32 support don't
break the existing build system for other platforms. I would definitely
feel guilty! Especially considering that, also if I started bothering the
whole world about bindings and Win32, I only did it for sake of completeness
and not because I *need* Win32 support!

Thank you again,

F.