[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[jdt-core-dev] why is jdtCompilerAdapter.jar not exploded in org.eclipse.jdt.core_3.1.0.jar
|
Hi,
An "ahead of time" compiled version of the Eclipse Java batch compiler
[1] will be included on Fedora Core 4. The recent "jar'd plugins" might
present a problem for this and I'm wondering if there is an upstream
solution. Before I explain the problem, here's a quick run down of how we
were building ECJ with 3.1M6 ...
After the jdt.core plugin was built, the jars were compiled to shared
objects:
gcj -g -fPIC -fjni -findirect-dispatch -shared -Wl,-Bsymbolic -O2 \
-o jdtcore.jar.so jdtcore.jar;
gcj -g -fPIC -fjni -findirect-dispatch -shared -Wl,-Bsymbolic -O2 \
-o jdtCompilerAdapter.jar.so jdtCompilerAdapter.jar
The jar.sos were then compiled into an ecj binary:
gcj -g -O2 --main=org.eclipse.jdt.internal.compiler.batch.Main \
-Wl,-R,%{_libdir}/%{name}/plugins/org.eclipse.jdt.core_3.1.0 \
jdtcore.jar.so jdtCompilerAdapter.jar.so -o ecj
Finally, gcj-dbtool is used to create a database of class signatures so
that gcj knows when to use the ahead of time compiled version of a
class. Details of how to set this up with gcj-dbtool can be found in
eclipse.spec which is in the eclipse module in
:pserver:anonymous@xxxxxxxxxxxxxxxxxxxxx:/cvs/dist.
With the latest i-builds we have to manually extract
jdtCompilerAdapter.jar because gcj doesn't support "jars inside of
jars". It would be much better for us if jdtCompilerAdapter.jar was
exploded inside org.eclipse.jdt.core_3.1.0.jar. So, is there a reason
why the classes from jdtCompilerAdapter.jar are not exploded? Would it
be reasonable to file a bug about this?
Thanks, Ben
1. We call the Eclipse Java batch compiler "the Eclipse Compiler for
Java" or ECJ.