[Xapian-devel] Available backends in xapian.h

[Olly Betts]

On Wed, May 04, 2005 at 04:43:29PM +0200, franz.g at tin.it wrote:
> 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.

I'm always interested to hear about compiler warnings (well, except for
the bogus ones about control reaching the end of a function which GCC
2.95 reports).  More often than not they highlight less than ideal code.
Plus if the compile is warning free you don't risk losing important
new warnings in a flood of others.

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

That's true.  I guess the best approach is to convert "\" to "/" in any
paths or filenames acquired from such tools.

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

I guess this is inevitable since Python is aiming to be a native Windows
application.

Is there an easy way to get python to tell us what the character
should be?  It seems messy to have our own logic to decide based on
the OS we're running under.

> If you say you're not sure about java...

I've just googled, and Java's CLASSPATH also needs ";" on Windows.  With
java you can get the separator using:

    System.getProperty("path.separator");

> Maybe Win32 problems should not delay the release of Xapian 0.9.0

I think there's more work to do than 0.9.0 could sensibly wait for
anyway, but I'm happy to merge in simple fixes.

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

Shouldn't do - they automated builds are good at picking up problems
like that.

Cheers,
    Olly