Re: java library installation issues
Egon Willighagen <egonw@subdimension.com> writes:
> Op dinsdag 03 april 2001 02:43, schreef Per Bothner:
> > I'd like to make some progress on standard Linux/GNU installation
> > standards for Java, and how GCJ fits into this.
>
> Have you taken over the maintainership? (Just wondering....)
I hope not ...
> > So to summarize: The builtin search path should be (in this order):
> > (1) each .jar file in /usr/share/java/$implementation
> > (2) each .jar file in /usr/share/java
> > (3) the /usr/share/java directory itself
>
> Is assume the latter is the "repository" version?
Yes.
> Why does it need to be one of these? Why not both, like in the
> current place?
Huh? It is - all three. I defined a *path* - a search order.
> The current policy also states that each Java program needs
> to have an executable in /usr/bin... This exec can figure things out,
> escpecially with its preknowledge...
But many Java packages are not programs, and in any case Java programs
depend on Java libraries.
The policy states that a package that installs a Java program must
install an executable in /usr/bin as an executable class or shell script.
But if the package can be built using gcj, then the executable should be
an actual executable.
> The directory /usr/share/java/gcj suggests some libraries of gcj,
> not for use with gcj (just brainstorming...) What about /usr/share/java-gcj/ ?
No strong preference, but I weakly prefer /usr/share/java/gcj.
> > For example, the library could be configured
> > to not use AWT when running on Gcj. In that case the generic
> > version would be installed in /usr/share/java and the AWT-less version
> > in /usr/share/java/gcj.
>
> This does not directly makes sense to me.... Ok, i agree that gcj is not
> "finished" yet, and that gcj does not support AWT yet. But do we want to
> have several versions of one executable? (Not voting against, i would like
> to see the same for libraries...)
I'm not talking about executables here - I'm talking about libraries.
> Sounds interesting... Could we build a meta-script that can generate
> /usr/bin/exec and /usr/bin/exec-gcj and solve these dependencies
> while auto-generating these executables?
Ideally, I should like to see automake support for building the
executables (when a suitable configure option is given). I've done
this (without taking much advantage of automake) for (the CVS version
of) Kawa: If you configure with --enable-gcj-compiled, it will use
'gcj -C' as the default for $JAVAC *and* it will build a kawa
executable, built using gcj, that can be installed in $prefix/bin. If
you don't configure with --enable-gcj-compiled, then instead a kawa
shell-script wrapper will be installed in $prefix/bin. My goal is to
encourage other Java packages to do the same.
> An second option is to have a system wide CLASSPATH set, that would
> include all jars...
This violates the Policy, and I don't want to change this. We cannot
require users to have to set their CLASSPATH in order to run Java
programs.
> > (2) Java applications compiled with gcj automatically find the
> > necessary ,so files, without the users having to explicitly list
> > them on the gcj command line.
>
> This is prevented by use of /usr/bin/exec scripts... (e.g. /usr/bin/ant)
> Thus prevening user to fiddle with command line/classpath options...
I don't understand this point. Perhaps by "prevented" you mean
"made unnecessary". (In which case note that that would be a non-standard
use of the word "prevented".) If so, not I'm talking about installing
a real executable program compiled and linked by gcj. In that case
you don't want to use a shell script if you don't need to.
--
--Per Bothner
per@bothner.com http://www.bothner.com/~per/
Reply to: