On Mon, Aug 5, 2013 at 5:39 AM, Mike Miller <mtmiller at ieee.org> wrote: > Had a moment to try this out briefly, works for me, mostly. Some minor > feedback from just building and running your example follows. > > $ ./configure --with-jni > checking for pkg-config... /usr/bin/pkg-config > checking pkg-config is at least version 0.9.0... yes > [...] > checking for LIBSTOKEN... yes > checking for LIBOATH... yes > 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. > 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. > 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? They provide the following files: /usr/share/java/java-atk-wrapper.jar /usr/lib/x86_64-linux-gnu/jni/libatk-wrapper.so /usr/lib/x86_64-linux-gnu/jni/libatk-wrapper.so.0 /usr/lib/x86_64-linux-gnu/jni/libatk-wrapper.so.0.0.18 /usr/lib/x86_64-linux-gnu/jni/libatk-wrapper.so only contains the JNI glue functions, and links to external libraries: NEEDED libatk-1.0.so.0 NEEDED libgdk-x11-2.0.so.0 NEEDED libgmodule-2.0.so.0 NEEDED libgobject-2.0.so.0 NEEDED libglib-2.0.so.0 NEEDED libpthread.so.0 NEEDED libc.so.6
