Mark Howard <mh@tildemh.com> writes: > Notes: > - should we use Sun style -classpath or GNU standard (and so gcj style) > --classpath ? -classpath should definitely by supported. Most package's upstream build systems will follow Sun. Patching each occurance is silly. Of course, each javac may support other dash or double-dash options as it sees fit. > - 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. Allowing a Unixy "silence is success" behaviour is better, so --version it is. > - 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'd leave the naming and other specifics up to the package. For example some compiler may support all our requirements already, calling the real binary *wrapper does not seem right. > - 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. Isn't this actually standard across compilers? jikes does it, gcj, too. > - 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) Leave it out for now. It's not really needed on Unix, but if many portable (heh) Java packages want it, we can add it later. I think both javac and java interface should respect $CLASSPATH. This is actually the only way to set the classpath that is respected by all VMs I know. -- Robbe
Attachment:
signature.ng
Description: PGP signature