On Mon, Aug 5, 2013 at 12:08:42 -0700, Kevin Cernekee wrote: > On Mon, Aug 5, 2013 at 5:39 AM, Mike Miller <mtmiller at ieee.org> wrote: >> [...] >> configure: error: '$JAVAC' undefined >> $ ./configure --with-jni JAVAC=javac # now it works > > I guess I should add JAVAC to the build instructions. Thanks. > > This check seemed overly picky - IMO it should check $PATH and > $JAVA_HOME too. I'll propose it to the maintainer. Sounds good. >> With my packaging hat on, do you think it would it be reasonable to >> split out the JNI API into a separate library? > > Along similar lines: if it is split into another library, should jni.c > be buildable "standalone" (against a preinstalled libopenconnect.so + > openconnect.h) or should it always be built from the openconnect > source tree? > > If it is a standalone library maybe the sources can live under > android/ or java/, or even in a separate repo. I hadn't looked before, but I now see that this depends only on the public openconnect API, so yes any of those could be done. Keeping it together in the openconnect repo is fine by me if it's fine by others. >> Are you expecting that this will be disabled on host builds / >> distributions? I assume so, since you're talking about Android and the >> default is disabled. > > Yes, the current implementation is intended for special builds > (Android) only as this is the near-term goal. > > For a distribution build, do you think it would be good to follow the > lead of libatk-wrapper-java and libatk-wrapper-java-jni on Debian? I honestly don't know enough about Java binding or packaging, but this seems like as good an approach as any. It seems to follow the Debian java library policy [1]. I suppose the jni library has low-level wrappers only and the jar adds an OO Java API around it. It at least suggests that separating the jni library is a good thing, which was my main concern above. [1] http://www.debian.org/doc/packaging-manuals/java-policy/x104.html -- mike
