[fedora-java] libvirt-java bindings

[Daniel Veillard]

On Thu, Jul 03, 2008 at 04:48:43AM -0400, David Walluck wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Daniel Veillard wrote:
> | On Wed, Jul 02, 2008 at 12:27:51PM -0400, David Walluck wrote:
> |> I thought Mary Ellen's email was to demonstrate how this method was bad,
> |> but you took this as a reason to adaopt it. Unless you think
> |> /usr/bin/ecj is not a valid Java compiler, then it's the method that's
> |> broken, not the compiler location.
> |
> |   Why would I think ecj is not a valid Java compiler ? Stop assuming
> | the only problem with ecj was that it needed the -source 1.5 flags.
> 
> My answer was not meant to be in response to the compilation problem,
> but the idea of assuming that following symlinks will eventually lead
> you to a valid JAVA_HOME directory. While this may be fixed to work in
> Fedora, I had doubt that this could work in general (or at least that it
> is the best/easiest solution).

  Okay. For not being the easiest, that's not surprizing !

> So, this is partly where the communication was lost: I was talking
> (ranting---or whatever you choose to see it as) about the
> packaging/configure issues and not the problems with the compilation.
> 
> But if `-source 1.5' needs to be passed for ecj (since it defaults to
> 1.6), then I think it makes sense to pass it as JAVACFLAGS (or whatever
> you want to call them) to every compiler, but I don't even remember now
> what the exact issue was.

  The problem was that Mary had to guess `-source 1.5' was the problem
(since there was a BuildRequires: java-devel >= 1.5 at least from a packaging
POV this should not have happened) and also being sure that adding this
flag won't break in other environment. Since it seems to be a generic
javac flag maybe that can be passed down every time:
  http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javac.html#options

  I had a javac command failing because of wrong args so I need to recheck
it wasn't -source

> |  1/ I needed a way to give the user the flexibility for the JDK used
> 
> I think you could do the following. You have
> 
> BuildRequires: jpackage-utils
> BuildRequires: java-devel >= 1.5.0
> 
> this means %{java_home} is defined, so in the spec you may just do
> 
> %{configure} --with-java-home=%{java_home}
> 
> Then a user would be expected to override the default value by setting
> JAVA_HOME.
> 
> Alternatively, you could just look for $JAVA_HOME being set, then in the
> spec you could do:
> 
> JAVA_HOME=%{java_home} %{configure}
> 
> Note that the %{java_home} macro as it's defined should honor the
> $JAVA_HOME setting in the shell.

  okay, so it seems you confirm the information in the previous mail

> |  2/ I needed the include paths for the JNI headers
> 
> You can use ${JAVA_HOME}/include or %{java_home}/include by default.

  well it also need %{java_home}/include/$system, or wherever jni_md.h
may be needed and it's often in a subdir (or sometime not available like 
in java-1.5.0-ibm-devel-1.5.0.7-1jpp.2.el4

> |  3/ I needed a -source 1.5 options when compiling against the Eclipse
> compiler
> |     (thanks a lot Mary for the solution !)
> 
> Depending on the issue you may want this in general. If you do a
> specific check for ecj, then you can't really assume the JAVA_HOME
> layout which is saving you the work of writing some custom scripts for
> each compiler

  I used the following:

JAVAC_FLAGS=
javac_version=`$JAVAC -version 2>&1`
case "$javac_version" in
    *Eclipse*)
        JAVAC_FLAGS="-source 1.5"
        ;;
esac

 that seems to work fine in practice.

> | people should do when packaging JNI related sources (including answers to
> | at least 1/ and 2/) both for configure.in and for the spec file, with
> | examples and explanations of what the various macro do. You will save
> a lot
> 
> I think that currently the Fedora Java Packaging Guidelines do not
> discuss issues related to Java and C much if at all.

  yes and IMHO that's part of the wall between Java and other communities
that we need to bring down. JNI makes it especially hard, maybe JNA will
lower the barrier, still we need to make things easier to reuse each-other
code.

  thanks !

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/