David Walluck wrote:
Daniel Veillard wrote:| - use the $JAVA_HOME as the user provided environment variable to point to| the top of the JDK tree | - in configure.in provide an option --with-java-home allowing to override it | - if still not defined try with /usr/lib/jvm/java Sounds good so far. You may also want to try other values for JAVA_HOME. I don't have an exhaustive list of these, but /usr/lib/jvm/java should be fine for any Linux distro that has jpackage-utils, so I think that should be sufficient. | - then check that $JAVA_HOME/bin contains the binaries for | javah/javac/javah/javadoc/jar to be used when building the binaries | - then look under $JAVA_HOME/include and $JAVA_HOME/include/$system for | the JNI includes I think you want something like CPPFLAGS="-I$JAVA_HOME/include -I$JAVA_HOME/include/linux". But if it's not linux, I don't know how standard the existence of $system is. | - we should look for the %{java_home} macro This is only good for the RPM build. If you depend on jpackage-utils you may assume it is defined. | - if found it should be passed as the --with-java-home value when running | configure In the RPM-build case, you can pass explicitly the default (or desired) Java home directory . You have already laid out the three basic steps for configure above: 1.) Use --with-java-home if set. 2.) If this isn't set, then you would read $JAVA_HOME from the environment. 3.) If that isn't set then you would check some pre-defined list of directories. At the very least /usr/lib/jvm/java. | - keep | Requires: java [ >= 1.5 ] | Requires: jpackage-utils | and | BuildRequires: java-devel [ >= 1.5 ] | BuildRequires: jpackage-utils | as the Java RPM dependancies Yes, since these are virtual provides specified by several vendors (GCJ, IBM, BEA, Sun) as long as they follow the JPackage standard. | - Indicates that when rebuilding manually, overriding %{java_home} on the | rpmbuild command line allows to pick a different JDK The switch happens for the end-user of the RPM spec file simply by redefining %java_home, e.g. rpmbuild --define 'java_home /usr/lib/jvm/java-gcj' or JAVA_HOME=/usr/lib/jvm/java-gcj rpmbuild | If yes can this be written directly somewhere in | http://fedoraproject.org/wiki/Packaging/Java#Specfile_Template | in a "configure" section along ant/maven it's hard to say how to standardize this process, since no one has written the canonical set of autoconf macros for this. Some macros exist in the autoconf macro archive, but they try to support many layouts (not just the linux standard layout).
We have some autoconf macros that seem to work reasonably well (they've been tested on various linuxes, 32- and 64-bit, as well as solaris and macosx).
They could probably use some tweaking, but would be a start: http://opennms.svn.sourceforge.net/svnroot/opennms/autotools/trunk/java.m4I just noticed we're bad people, and don't have any copyright/license info on it, I'd be happy to make them whatever license makes them easy on everyone. =)
To use it, we do: ONMS_CHECK_JDK([1.4]) AC_CHECK_HEADER([jni.h], [], [AC_MSG_ERROR([cannot find jni.h header])]) ...and in the .am: lib_LTLIBRARIES = libjrrd.la libjrrd_la_SOURCES = rrd_jinterface.c libjrrd_la_LDFLAGS = -module -avoid-version $(JAVA_SHREXT_COMMAND) .java.class: -mkdir -p $(classdir) $(JAVAC) $(JAVACFLAGS) -d $(classdir) $< Haven't figured out a nice way to to javah stuff though, still very manual: rrd_jinterface.c: org_opennms_netmgt_rrd_rrdtool_Interface.horg_opennms_netmgt_rrd_rrdtool_Interface.h: org/opennms/netmgt/rrd/rrdtool/Interface.class
$(JAVAH) -classpath $(classdir) org.opennms.netmgt.rrd.rrdtool.InterfaceDoes that help? It's still a little opennms-specific right now, I think, but would be a place to start.
-- Benjamin Reed The OpenNMS Group http://www.opennms.org/
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-java-list mailing list fedora-devel-java-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
