problem with bindings configure script

[Olly Betts]

On Wed, Sep 14, 2016 at 01:10:24PM -0400, John Bankert wrote:
> I think the confdefs.h issue was due to the fact that I was using
> XAPIAN_CONFIG to point to the configure script, rather than the
> xapian_config executable created when making xapian_core, as pointed out by
> James.

Ah, I can see that could cause this problem - the other configure
probably cleans up the confdefs.h which the bindings configure
created.  Not sure I see an easy way to avoid that - perhaps the
XO_LIB_XAPIAN macro should reject XAPIAN_CONFIG if its leafname
is "configure".

> Also, as a general note, when trying to make the bindings, I had a problem
> when make was trying to compile the java source in org/xapian
> 
> The following line:
> 
> $(JAVAC) $(JAVACFLAGS) -classpath $(srcdir)$(JAVA_PATHSEP). -d . $<
> 
> generated the following error javac: no source files
> 
> Some experimentation on my part led me to change the Makefile to read
> 
> $(JAVAC) $(JAVACFLAGS) -classpath $(srcdir) -d . $<
> 
> and I was able to successfully make the bindings. Haven't had a chance to
> run any samples yet, but wanted to follow up on this. Thanks again for your
> help.

What does this report:

grep JAVA_PATHSEP java/Makefile

JAVA_PATHSEP should be either ':' or ';' depending which character is
used to separate paths by javac on the platform you're using.  But we
get the value by compiling a small Java program to query
System.getProperty("path.separator") so it is odd if we have the wrong
one, even on Cygwin.  I guess your java and javac could be mismatched
though.

You could check that specifying the other one to the one which was
probed works - so if the grep shows ':' then:

make JAVA_PATHSEP=';'

Otherwise:

make JAVA_PATHSEP=':'

Just removing '.' from the classpath would break out-of-tree developer
builds (and removing $(srcdir) would break out-of-tree user builds).

I guess we could probe for JAVA_PATHSEP by trying ':' or ';' in a test
invocation of $JAVAC and seeing which works - that would avoid the
potential mismatch I hypothesised about above.

Cheers,
    Olly