[fedora-java] Enhanced aot-compile script

[Gary Benson]

Fernando Nasser wrote:
> 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.
[snip]
> 
> 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
was awful...

> 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.

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
to fail.

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
in turn.

> 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
BuildArch.

> 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.

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
example.

Cheers,
Gary