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@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
--
fedora-devel-java-list mailing list
fedora-devel-java-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
