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: @[EMAIL PROTECTED] 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: @[EMAIL PROTECTED] 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
