Quoting Per Bothner <[EMAIL PROTECTED]>: > > 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. Ok, in addition to the current Debian policy, a third, preferred option, being the gcj compiled library. > > 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. Indeed. But the principle holds that in Debian, with dependencies, that a certain executable exactly knows where to find a certain library. The build and run dependencies basically refer to an other package of which the file structure is determined. Once a maintainer changes this dir structure and thus file locations it possibly breaks many packages... This is why policies are so important. > > 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. My point is that in /usr/share/java/gcj it seems to refer to libraries used for gcj, instead of libraries compiled with gcj. Like in /etc/some-program, where settings are placed for a certain program. > > > 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. Sorry. I was not completely clear in what i wanted to say. The library would have the same functionality, with and without AWT (for example). So the same holds for a certain application that uses this library. A certain program that normally uses AWT, but wants to use the gcj compiled version, has to fall back to non-AWT. This would indeed mean that only one binary would suffice... Now comes the reason why i failed to respond correctly to the issue; How does a Java program (in Java byte code), use a gcj compiled library? > > 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. Do you mean that in order to use gcj compiled libraries the program itself has to be gcj compiled as well? Ok, i think i begin to see what you're aiming at... Given Java source code that compiles with gcj to architecture-specific code, you would make it (Debian) policy to compile with gcj in order to use the gcj compiled libraries? Or maybe, to have two conflicting packages program and program-gcj? Preferably, based on the same source code, to prevent forking... > > > (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".) No, actually a meant prevent... i do not just want it unnecessary, but the user should not have to use commandline options at all... and by means of the policy prevent that this will ever be necessary. Egon -------------------------------------- FREE ANONYMOUS EMAIL! Sign up now. http://www.subdimension.com/freemail
