Bug 785020

NOTE: This would also introduce the need for CMake to contain a dependency on "jpackage" (where the "%{_jnidir}" macro is defined.

The only reference to JAVA_LIB_INSTALL_DIR I can find in the cmake code is in the comment in UseJava.cmake:

#    If the target is a JNI library, utilize the following commands to
#    create a JNI symbolic link:
#
#       set(CMAKE_JNI_TARGET TRUE)
#       set(CMAKE_JAVA_TARGET_VERSION 1.2.0)
#       add_jar(shibboleet shibbotleet.java)
#       install_jar(shibboleet ${LIB_INSTALL_DIR}/shibboleet)
#       install_jni_symlink(shibboleet ${JAVA_LIB_INSTALL_DIR})

So I'm really at a loss as to how you expect to "embed the %{_jnidir} logic inside the cmake system".  Do you want to add -DJAVA_LIB_INSTALL_DIR=%{_jnidir} to the %cmake rpm macro?  I would prefer a %{cmake_jni} macro in jpackage similar to %{cmake_kde4} in kde-filesystem.

I concur with orion, 
1.  It's not clear what you're asking for , but...

2.  My best guess is that what you want to achieve can be done elsewhere more easily to provide the rpm macros you want, though I'm curious what's so bad about the current/status-quo of just using:
%cmake -DVAR_INSTALL_DIR:PATH=/var -DBUILD_PKI_CORE:BOOL=ON
-DJAVA_LIB_INSTALL_DIR=%{_jnidir} ..
(or perhaps to avoid all the copy-n-paste duplicated code, and for convenience, do define your own %{cmake_jni} somewhere), say in /etc/rpm/macros.jpackage or even /etc/rpm/macros.jpackage-cmake owned by a subpkg jpackage-utils-cmake if you insist on avoiding a dependency on cmake.

The end state is that when I build,  the CMake system should determine where the JNI libraries are,  and I should not have to explicitly pass that value on the CMake command line.

cmake -DJAVA_LIB_INSTALL_DIR=/usr/lib64/java  ...  

should not be necessary.  THe only time that JAVA_LIB_INSTALL_DIR  would be other than /usr/lib64/java  on a 64 bit system would be when compiling 32 bit native libraries,  a very uncommon undertaking.

In this case there seems to be a couple issues:

- jss is not packaged according to the current guidelines and puts jss4.jar in %{_libdir}/java instead of %{_libdir}/jss.

- In cmake if you:

  include(GNUInstallDirs)

you will get a variable called CMAKE_INSTALL_LIBDIR set to lib or lib64 as appropriate.  This can be use by the project to set paths, e.g.:

set(JAVA_LIB_INSTALL_DIR /usr/${CMAKE_INSTALL_LIBDIR}/java)

(In reply to comment #5)
> In this case there seems to be a couple issues:
> 
> - jss is not packaged according to the current guidelines and puts jss4.jar in
> %{_libdir}/java instead of %{_libdir}/jss.
> 

There was a lot of discussions surrounding the placement of JNI jar files as documented in:

* Bugzilla Bug #665576 - "build-classpath swt" fails on 64bit
* Bugzilla Bug #734590 - Refactor JNI libraries for Fedora 16+ . . .

That being said, I do not believe that the existing instructions have been updated to document these decisions:

* http://fedoraproject.org/wiki/Packaging:Java#Packaging_JAR_files_that_use_JNI

However, for simplicity, I will add symlinks to the three JNI components that Dogtag utilizes:

* %{_libdir}/jss/jss4.jar -> %{_libdir}/java/jss4.jar
* %{_libdir}/osutil/osutil.jar -> %{_libdir}/java/osutil.jar
* %{_libdir}/symkey/symkey.jar -> %{_libdir}/java/symkey.jar

While this is somewhat reversed from some of the statements in the existing Fedora packaging guidelines for JNI, I believe it should suffice to add these benign (and somewhat informational) symlinks.

> - In cmake if you:
> 
>   include(GNUInstallDirs)
> 
> you will get a variable called CMAKE_INSTALL_LIBDIR set to lib or lib64 as
> appropriate.  This can be use by the project to set paths, e.g.:
> 
> set(JAVA_LIB_INSTALL_DIR /usr/${CMAKE_INSTALL_LIBDIR}/java)

I have created a TRAC Task for the integration of these changes:

* https://fedorahosted.org/pki/ticket/109