Fernando Nasser wrote:
I was thinking of having a 'aot-compile' command that would
all tasks related to aot compilation.
by itself would perform the additional compilation steps necessary to
generate the .so files etc., as currently done.
aot-compile --install <install arguments>
would allow a conditional installation step
and so forth.
Firstly, a minor point. I guess you want this so that the former can
go in %build and the latter can go in %install? I wanted to do this
anyway, but separating the process turns out to be a nightmare because
what's in the build tree after %build is almost never anything like
what's in the install tree after %install. Not everything is copied
over, and what is is almost always renamed.
FWIW katana _was_ split in this way: packages frequently required tens
of options just to tell it what was going to be installed where. It
In addition to that, 'aot-compile' would either work or be a
depending on certain conditions, like the presence of GCJ in the
system, and/or some system-wide or local override configuration
The fact that aot-compiled rpms have more files than their uncompiled
equivalents will make this far less neat than you perhaps think. Each
package will need a conditional block in its %files list. It's not
something that can be done simply with globs.
That aside, having the database rebuilding as an alternative (so
possibly a no-op) would also cause problems. Imagine this:
1. User has GCJ as their JVM.
2. a) User installs some Fedora packages.
b) GCJ database is rebuilt into a consistent state.
3. User switches to some other JVM.
4. a) User installs some more Fedora packages.
b) GCJ database is not rebuilt.
5. User switches to GCJ as their JVM.
The user has ended up with a broken database. His applications will
be slower, and in some (admittedly broken) cases will suddenly start
Rather than being an alternative, the rebuild command would need to
rebuild all databases that could be installed on the system. This
could be done by for example having all JVMs drop scripts in some
database, and having 'aot-compile --rebuild' or whatever call them all
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
That's certainly possible: aot-compile-rpm already checks your
IMPORTANT: please note that aot-compile should not be tied to GCJ,
but instead be a characteristic of any Java that is capable of
Sure. This doesn't preclude us from putting the present, GCJ-specific
aot-compile-rpm into the gcc-java rpm, and I still think we should
proceed with this.
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.
How about making them even more generic and mandating that all
JPackage rpms call certain scripts at certain points. At the end of
%install, for example, you could require that all packages invoke
jpackage-install, and similarly %post would have jpackage-post and
%postun would have jpackage-postun.
Each script could do both generic JPackage stuff and call specific JVM
stuff. Under your system jpackage-install would call aot-compile-rpm
if GCJ was selected as your JVM, and jpackage-post and -postun would
do the database rebuilding. The scripts could do allsorts: the %prep
script jpackage-prep could check for bundled jars and classes for