FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development Java

 
 
LinkBack Thread Tools
 
Old 07-03-2008, 09:44 AM
Daniel Veillard
 
Default libvirt-java bindings

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@redhat.com | 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@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
 
Old 07-03-2008, 09:57 AM
Daniel Veillard
 
Default libvirt-java bindings

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@redhat.com | 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@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
 
Old 07-03-2008, 12:12 PM
Benjamin Reed
 
Default libvirt-java bindings

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.m4

I 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.h

org_opennms_netmgt_rrd_rrdtool_Interface.h:
org/opennms/netmgt/rrd/rrdtool/Interface.class

$(JAVAH) -classpath $(classdir) org.opennms.netmgt.rrd.rrdtool.Interface

Does 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/


--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
 

Thread Tools




All times are GMT. The time now is 07:16 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org