Re: GCJ Native Proposal
On Tue, Mar 15, 2005 at 09:13:44AM +0100, David Schmitt wrote:
> On Sunday 13 March 2005 22:05, Wolfgang Baer wrote:
> > But just for discussion - wouldn't there be a third possibility ?
> > (Sorry if this is a stupid question !).
> >
> > What about a creating a second source package which build-depends
> > on the java source package to produce the native binary. This wouldn't
> > hit the buildds, but put the burden onto the maintainer as he has to
> > achieve that both source packages are in sync. The binary source package
> > therefore wouldn't include any source only the rules file to produce a
> > -jbi package.
> >
> > I don't know if this is reasonable / possible ? Is there something
> > like source package dependencies in debian atm ?
>
> Hmmm, the idea has its merits. Implementationwise, it'd make more sense to
> have $lib-jbi Build-Depend on $lib-java. The $lib-jbi would have to be a
> sperate source, but I imagine that cuold be a very small standard template,
> which fetches most of it information via grep-dcrtl at build-time, thus being
> essentially the same for all -jbi packages out there. Both can be uploaded at
> the same time, the buildds can sort it out for themselves.
I think this idea puts more burden on the shoulders of the package
maitainers then really needed. The native library and and the according
jar has to be always in sync. This means the native library depends on
exact same version as the jar. We need to install both always a
reasonable large Java aplications always play tricks with the bytecode.
E.g. Eclipse loads bytecode from its own jars at runtime and tries to
run in. GIJ/GCJ then uses the native code too but the bytecode needs to
be there in the same version as GCJ calcs a checksum over the bytecode
to find the according native code,
Michael
--
Java Trap: http://www.gnu.org/philosophy/java-trap.html
Reply to: