-----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).
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.
| 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.
| 2/ I needed the include paths for the JNI headers
You can use ${JAVA_HOME}/include or %{java_home}/include by default.
| 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
| Your answer as I understood it was:
| - that I should ignore 1/
No, just that the issue was already solved.
| - that there were some RPM macros (undefined, just a list of macro
names)
I thought the macros were self-exaplanatory, but the basic point of
their usage would be if you want to do something like
%{configure} --with-java=%{java}
vs.
%{configure} --with-java=%{java_home}/bin/java
| 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.
- --
Sincerely,
David Walluck
<david@xxxxxxxx>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iEYEARECAAYFAkhskmsACgkQItObMyg2XCU42gCfXIpD+QHo/PYlYP1ACiIf71kK
aygAoKco5eNP02f7hiLsvqhbQFvUXEca
=gvhG
-----END PGP SIGNATURE-----
--
fedora-devel-java-list mailing list
fedora-devel-java-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
