On Fri, Oct 04, 2002 at 02:19:17PM +0100, Mark Howard wrote: > On Fri, 2002-10-04 at 11:48, Ola Lundqvist wrote: > > Policy feedback is apriciated. How do you think the text should be > > instead?
Hi Thanks for the text. > 2.2. Java compilers > > Java compilers must depend on java-common and the needed runtime > environment (java1-runtime and/or java2-runtime). > > Where possible, java compilers should include a javac wrapper named > compilername-javac-wrapper (e.g. gcj-javac-wrapper). If this complies to > the following terms, then the package should provide java-compiler or > java2-compiler and use the alternatives system for the name 'javac'. I think we have come to a conclusion saying that java2-compiler is not necessary. > Java compilers not satisfying these terms must not provide > java-compiler. Sounds good. > - Generated output is standard java bytecode [as defined by ...??] and > stored in files of the form MyClass$MyInnerClass.class. Do anyone know of a good reference? > - javac --version will print the full name and version of the compiler Ok. > - Command line arguments are of the form javac [options] sourcefiles > - The following options must be implemented. Other options may exist > also > -classpath classpath > classpath is a colon separated list of jar files and directories > searched for compiled java bytecode. > -d directory > sets the destination directory for the class files. > > > Notes: > - should we use Sun style -classpath or GNU standard (and so gcj style) > --classpath ? Should we enfoce both of them? > - If packages build-depend on java-compiler, --version will be useful to > see which one is being used. Alternatively, perhaps it would be a good > idea to say that this information should be printed whenever javac is > run - this would be especially useful for users who aren't familiar with > the alternatives system. Well the javac program should be quiet I think. > - Not sure if wrapper naming is needed, but it might make it clearer to > have such a convention (it would differentiate between upstream compiler > and the wrapper) I do not think it is necessary. In some cases you might not need a wrapper. > - Sun's javac creates directories below the -d directory following the > class name e.g. -d work com.debian.test -> work/com/debian/test.class. > This would be slightly more difficult to implement in a wrapper script, > so I think it is best to say this shouldn't happen. Well then the upstream have to change, right? > - should @files also be included? (allows the user to give the name of a > file containing source file names rather than listing the source files > directly) I do not know (never used it). What do other people think about this? > Also, something similar should be done for section 2.1: > 2.1. Virtual machines > > Java virtual machines must depend on java-common. > > If possible, they should provide a 'java' wrapper script named > jvm-name-java-wrapper [again, not sure if necessary] to be used with the > alternatives system. If the wrapper complies to the following terms then > the package should provide java-virtual-machine and java1-runtime or > java2-runtime as appropriate [?is this correct?] > > The java wrapper should allow the following calling conventions: > java [ options ] class [ argument ... ] > java [ options ] -jar file.jar [ argument ... ] > > The following options must be implemented, although others may also > exist: > -classpath > [same as above] > > JVM's should have a CLASSPATH predefined which include the needed > runtime environment. Yes. Now to the question. Should it override the CLASSPATH and/or -classpath? I do not think so. It should be written in the policy. > If a given source (like the JDK does) brings both a compiler and a > virtual machine, you may name the compiler package xxxx-dev. Well you do not have to say such things in policy I think. Regards, // Ola > -- > > +----------------------------------------------+ > | Mark Howard cam.ac.uk mh344@ | > | http://www.tildemh.com tildemh.com mh@ | > +----------------------------------------------+ -- --------------------- Ola Lundqvist --------------------------- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---------------------------------------------------------------
