[fedora-java] libvirt-java bindings

[Daniel Veillard]

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 at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/