problem with bindings configure script

[John Bankert]

Olly,

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.

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.

John

On Mon, Sep 12, 2016 at 6:31 PM, Olly Betts <olly at survex.com> wrote:

> On Mon, Sep 12, 2016 at 11:07:10AM -0400, John Bankert wrote:
> > That worked, thanks, but with a caveat. I don't know if this is a
> > limitation of autoconf/configure, but jni.h wants to include jni_md.h,
> > which is located in JNI_INCLUDE_DIR/win32, which is not automatically
> > searched. I was able to work around this by moving jni_md.h from the
> win32
> > sub directory to the same directory as jni.h. No idea who's bug this is,
> if
> > it is legitimately a bug, but putting this tidbit out to the list in case
> > someone other than me runs up against it.
>
> Ah, that's easy to fix then.
>
> The jni_md.h file contains platform-specific stuff, and the name of the
> directory it is in varies by platform (though oddly not by architecture
> - e.g. it seems to be "linux" for all Linux architectures, whether they
> are 32- or 64-bit, despite part of its purpose being to provide typedefs
> for jint, jlong, etc).
>
> So we just need to include cygwin in the mapping to "win32" here.
> Committed to git master in 633b04159966c376e3ac60c05081a58716959685 -
> I will backport that to 1.4.x and 1.2.x.
>
> Copying jni_md.h should be fine as a workaround for now.
>
> However, this doesn't seem to explain the messages about "confdefs.h"
> - do you still see messages like these having copied jni_md.h over?
>
> > > > checking for jni.h... cat: confdefs.h: No such file or directory
>
> Cheers,
>     Olly
>