[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

Hallo Daniel,

* Daniel Bonniot wrote:
>>FWIW, I think having a package build relying on /usr/bin/javac is a very
>>bad idea.  You want to be absolutely sure that a package builds out of
>>the box, and IMHO this means you should explicitly build-depend upon
>>*and* call a complier that you know will work.  Note that just the
>>build-depends is not enough, since /usr/bin/javac is currently under the
>>management of alternatives, and so there's no guarantee that javac
>>actually calls the compiler that you build-depended on.

So here as well, we have to get a way to distingush beween 'unfree'
(should be sun compatible and so we can just use the inbuild
javac.Main or 'modern' build.compiler) ones and free ones like jikes,
kaffe, eclipse and gcj. The last four have to be used by specifying a
'build.compiler' to ant, so IMO this should be ok. It shouldn't be a
big deal to deal with such a situation. You could then use the jar
description files (hm, should be renamed to 'java config files' or
so... :) to get the bootclasspath and so on.

I don't think that there are many packages, which have a dependency on
plain /usr/bin/javac. Most of the packages use ant. Even the
build-native of eclipse is done through ant.

what becomes quite cleare here, is, that this proposal will only work
with all the 'helper' scripts around, which will make packaging less a
pain. I hope Stephan can comment on this, since he maintains the CDBS
ant classes. 

>I think we should distinguish are two different kinds of builds:
> 1) by the Debian build daemon
> 2) by a user that downloaded the package source

There is nothing to distingush between this two kinds. Both of them
simple have to work out of the box and both are actually using the
same tools.

IMO the only cases we have to distingush are 'javac and poackaging'
and 'javac and manual use'. For the last, it is IMO enough to say,
that javac can be any of the javc compiler and the user shold look
into the javac manual page. /usr/bin/editor can also be everything
from nano to emacs/vi.

>If it really works like that, I can build-depend on jikes |
>java-compiler, and call /usr/bin/javac. In 1, since no java compiler is
>build-essential, /usr/bin/javac will indeed be jikes. In 2, the user has
>the desired flexibility. Idem for a JVM/runtime.

Any coments? I'm not sure, if the buildd can be tricked that way.
Anyway, a user having a compile error 'at home' is also a grave bug,

Jan Schulz                     jasc@gmx.net
     "Wer nicht fragt, bleibt dumm."

Reply to: