Java bindings: change default installation directory of JNI shared lbrary and control it with GDAL_JAVA_JNI_INSTALL_DIR

[rouault]

No description provided.

[landryb]

thanks @rouault, that makes total sense and matches the previous autoconf behaviour.

[rouault]

matches the previous autoconf behaviour.

not exactly. the jni lib was installed in ${libdir}, not ${libdir}/jni . I've adopted the later based on the Debian conventions but it doesn't look there's a universal concensus on where to install those jni libs

[coveralls]

coverage: 66.972% (-0.001%) from 66.973% when pulling ab0acef on rouault:GDAL_JAVA_JNI_INSTALL_DIR into 6e268bb on OSGeo:master.

[landryb]

matches the previous autoconf behaviour.

not exactly. the jni lib was installed in ${libdir}, not ${libdir}/jni . I've adopted the later based on the Debian conventions but it doesn't look there's a universal concensus on where to install those jni libs

yes it seems jni is a debian thing, by default i've been told that the jvm looks into LD_LIBRARY_PATH/java.library.path which might differ depending on distros/oses.. @sebastic any opinion ?

[sebastic]

yes it seems jni is a debian thing, by default i've been told that the jvm looks into LD_LIBRARY_PATH/java.library.path which might differ depending on distros/oses.. @sebastic any opinion ?

The jni subdirectory is a Debian convention, from the Java Policy:

If a Java library relies on native code, the dynamic libraries containing this compiled native code should be installed into the directory /usr/lib/jni.

Fedora has a different convention:

• JNI shared objects MUST be placed in %{_libdir}/%{name}

[...]
Macro expansions
%{_jnidir} expands into %{_prefix}/lib/java, even on 64-bit systems. Java packages using JNI do not support multiarch installation.

[rouault]

@landryb @sebastic Do you think this is a move in the right direction ? Obviously the default value of the CMake variables will have to be customized in most situations

[sebastic]

Do you think this is a move in the right direction ?

No sure. It's easy enough for packagers to move the files to the expected location for their distribution.

Since the Debian package doesn't include the Java bindings any more, it's all moot.

[landryb]

i think it's a move in the right direction because as a packager i wouldn't expect the .so to end up in the same place as the jars, but i agree it all depends on the default settings/lookup paths of the jdks for both types of files.

and it's more 'standard' to use cmake provided configure options to set the paths, rather than moving files post-install...