Hi,
I was thinking of having a 'aot-compile' command that would perform all tasks
related to aot compilation.
For instance:
aot-compile
by itself would perform the additional compilation steps necessary to generate
the .so files etc., as currently done.
aot-compile --rebuilddb
would do the rebuild-gcj-db thing
aot-compile --install <install arguments>
would allow a conditional installation step
and so forth.
In addition to that, 'aot-compile' would either work or be a no-op, depending on
certain conditions, like the presence of GCJ in the system, and/or some
system-wide or local override configuration mechanism.
This way, aot-compile statements can be added to an RPM spec file and that same
spec file can be used to build bytecode or pre-compiled RPMs, depending on the
settings. Adding just this script to jpackage-utils would allow us to eliminate
differences between the spec files upstream and in other distros, except for
having to remove the "BuildArch: noarch" line.
It seems that there are a few cases to consider:
1) gcj is not installed ==> automatic ==> do not precompile
2) gcj is installed, but we don't want to pre-compile ==> override with either
system or local config (we could test for "BuildArch: noarch"...) ==> do not
precompile
3) gcj is installed, and we want to pre-compile ==> automatic ==> precompile
There are perhaps some other conditions, like you want to build the bytecode
with another Java and then use gcj to pre-compile...
IMPORTANT: please note that aot-compile should not be tied to GCJ, but instead
be a characteristic of any Java that is capable of pre-compilation. QUESTION:
how to accommodate the differences in pre-compilation mechanisms? In any case,
we should try and keep the command names generic so if necessary one day the
JVMs that are AOT-capable can provide alternatives for those.
Regards to all,
Fernando
