Re: GCJ Native Proposal
On Tuesday 15 March 2005 14:10, Michael Koch wrote:
> > 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,
Pardon my ignorance regarding java issues, I'm just a creative mind floating
some ideas around.
Can all .jars be recompiled into .sos? Then it would even be possible to have
a bunch-o-scripts hanging on debian-devel-changes and automatically download
the -java package, create a -jbi from a template and do an upload. The rest
of work is done by the autobuilders.
The template would look like this:
Source: @parent@-jbi
Section: @parent-section@
Priority: @parent-priority@
Maintainer: @parent-maintainer@
Uploaders: @parent-uploaders@
Build-Depends: @parent-binary@ (= @parent-version@), gcj-4.0
Standards-Version: 3.6.1
Package: @parent@-jbi
Architecture: any
Depends: @parent@ (= @parent-version@)
Description: @parent-description@ (native)
This is the nativly compiled version.
.
@parent-long-description@
Where the @@ parts would have to be extracted from the Arch: all package.
At build-time the installed jar had to be located, compiled and put into the
package with something like
dpkg -L @parent@ | grep jar$ | while read jar; do
mkdir -p build/$(dirname $jar)
gcj $(GCJFLAGS) $jar -o build/$jar.so
done
cp -r build/* $(DESTDIR)
But probably I have missed something important which can't be automated :(
Regards, David
--
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir über ein septisches medium ;)
-- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Reply to: