splitting jni libs into it's own package
Hello,
Whats the best way to split JNI libs into it's own package?
I have three arch dependend packages, which contain some small jni
libs and a binary starter. They are now part of the java packages,
which need them. This means that I need to compile all parts (slow, I
can't split the compile into parts...) and then package a small arch
dependend lib with each java package (bloats the archive).
To give some numbers:
libswt*java: around 1 MB, half of it is arch dependend
Eclipse-platform: 25MB, 20KB arch dependend
Build Time HD space: 400MB+
Build Time: 20min on my system
Buidl time for only the arch dependend parts: a lot less space and time.
I'm now trying to get this sorted out and came up with three different
versions:
Spliting each package into two packages
libswt*-java + libswt*-jni
eclipse-platform + libeclipse-jni
Pro:
. means that I can have clear dependencies (wrt to GUI Toolkits) from
each package.
. Fast to compile (arch dep parts)
. cleanest solution
Con:
. Small *-jni package libeclipse-jni (less than 50k content, three files).
No idea, if that will be accepted. The rest will be around 300k
content.
Putting all jni parts into one libeclipse-jni package
Pro:
. fast to compile (arch dep parts)
. one jni package, about 800k content, 9 files
. easiest
Con:
. No clear dependencies wrt GUI Toolkits: swt motif will pull in
gtk dependecies
Only splitting eclipse-platform
Pro:
. One small jni package (see above), but not anymore 20+MB Arch: any
package.
. clear dependencies wrt to GUI toolkits
Con:
. No time speedup with arch dep
Any ideas?
This all sucks, as this is a release, which I didn't expect to make,
but I hope to get it into testing.
Actually I wanted to make this step in the 3.0 packages, but they will
take some time longer, as the build script generator, which comes with
eclipse isn't up to date wrt the latest changes in eclipse. So I need
to package this 2.1.x maintainance release...
Jan
--
Jan Schulz jasc@gmx.net
"Wer nicht fragt, bleibt dumm."
Reply to: