On Thu, Jul 03, 2008 at 05:05:52AM -0400, David Walluck wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
It seems to be here, back up to RHEL4, so from my own set of systems
this looks fine.
| - 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.
yeah it's a bit painful, but I prefer not hardcode the system, for example
libvirt is used in Solaris and can compile on Windows, and examples on the
sun documentations seems to imply $system being respectively solaris and
windows on those platforms.
I used
------------------
case "$build_os" in
*linux*)
system="linux"
;;
*)
system="$build_os"
;;
esac
if test -f $SDK/include/$system/jni_md.h ; then
JNI_CFLAGS="$JNI_CFLAGS -I$SDK/include/$system"
else
if test "`find $SDK -name jni_md.h`" != "" ; then
head=`find $SDK -name jni_md.h | tail -1`
dir=`dirname $head`
JNI_CFLAGS="$JNI_CFLAGS -I$dir"
fi
fi
------------------
I think if you substitute SDK by JAVA_HOME you should get something
in line with the expectations, while being portable (and extensible)
| - 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.
okay
| - 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.
okay
| - 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.
I found that to be true even on ancient systems, which was my main worry
about a jpackage-utils dependancy, so this is fine (and that part is well
documented already)
| - 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
makes sense.
| 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).
Sure, we can try to specify what a call to configure would look like and
have each author write his own code to do it. A better approach might be
to write a set of canonical m4 code that might be used to satisfy those
requirements.
my experiance with auto* is that the first person who write the macros
put them in the configure.in, and they get copied/modified over by
everybody else because cut'npaste is the simpler solution and doesn't
add any dependancy on the version of autoconf/automake being used. It's
a bit sad, it's a bit of a mess, but works somehow.
Minimally all that is required is to read the value of $JAVA_HOME
since
you can assume a monolithic layout for the rest of the binaries and
directories used for building.
Okay I now have a clearer idea, validated with your expertise :-)
Now, that's progress, once I have something which seems to work correctly
I will resubmit for Fedora review, and try to expose the steps,
thanks a lot !
Daniel
--
Red Hat Virtualization group
http://redhat.com/virtualization/
Daniel Veillard | virtualization library
http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/