Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Dalibor,
* Dalibor Topic wrote:
>> All in all, I think we first need a better working policy, before we
>> could start thinking about such a project.
>Fair enough. I think that such a project is crucial to making free java
>software work well in debian.
Thats why I did propose this here :)
>> JAVA_HOME = $(shell for jh in $(JAVA_HOME_DIRS); do if [ -d "$$jh" ]; \
>> then echo $${jh}; exit 0; fi; done)
>What do jh and JAVA_HOME do (in this case)? What does eclipse need JAVA_HOME
>for?
jh is just the 'running index' (crude translation from german). Like
foreach i in JAVA_HOME_DIRS, where JAVA_HOME_DIRS is a list of known
working JAVA_HOME sites, which will work.
Eclipse needs JAVA_HOME, because of several reasons, all which could
be remodeled:
* it is passed to ant, which uses JAVA_HOME to get a bin/java
* JNI headers are gooten from there.
>Well, this raises the question what the interface to javac should be:
>the one from javac 1.0, 1.1, 1.2, 1.3 or 1.4, or 1.4.2? Should it
>include all options, or just the important ones? And so on ... the
>same for java. Does debian's java policy proposal cover that?
>Otherwise it would be useless in the eclipse vs. -cp case ;)
So the propoasel should either add a 'build.compiler', so that it at
least works with ant (every other usecase should work via alternatives
for the man pages) or propose some base options, which have to be
implemented (maybe better for /usr/bin/java alternatives)
>> The Mainatainer of the package will be the "Java Build Demon". :/
>> Hopefully helped by as much policy and helper scripts as possible...
>I think that puts too much burden on the maintainer. Having a good policy is
>all well, but without actually being able to confirm that a package works with
>a VM on say superh-linux, it's not really helpful, beside placing additional
>buerocratic load on the maintainer, I think.
IMO, thats what being a debian maintainer is about. Or is this
situation different form getting a 'Serverity: Grave, Compile Error on
mipsel' bugreport? We don't have to think about different arch, but
about differene JVMs...
>> Eclipse compiler is 'free', so we have already a Java1.4a/1.3 compiler,
>> which passes all of suns 'testing Kits'... Maybe I should split this
>> package out so that it can go into main.
>it passes the regression tests from sun? do you have a link? how does it fare
>on jikes' compiler test suite jacks?
Checkout the latest 'Whats New in M3' on eclipse.org (Thats the 3.0
stream, not the packaged 2.1.1). Basicly they test every 'strange' bug
agains javac (1.3 and 1.4) and jikes, so they should be fairly
accurate compared to this both.
>the rhug guys sperated it out, and apparently made it faster than jikes by
>compiling it with gcj ;)
I have to have a look into that. The problem is, that I don't have
that much time in the moment :(
Anyway, this gcj isn't in debian yet.
Jan
--
Jan Schulz jasc@gmx.net
"Wer nicht fragt, bleibt dumm."
Reply to: