David Walluck wrote:
> By the way, I don't like how aot-compile combines the %build and
> %install steps.
I'm guessing you're talking about aot-compile-rpm here...
> Can't it run twice, once during build where it creates the .so
> files, and once during %install where it installs the created .so
> files to the correct path, or something like this?
Not really. The original reason for writing aot-compile-rpm was
that it was hard to maintain natively compiled packages with its
predecessors. This was slowing Fedora's development in at least
two areas:
a) I maintain _a_lot_ of packages in Fedora that are independently
maintained by the application server team. Fedora constanly lags
the appserver because the (many) appserver developers can pull in
new versions far faster than I (one person) can port them to
Fedora. Now that these have been ported to Fedora's free Java
environment it makes sense for at least some appserver development
to occur on Fedora for greater community involvement, which of
course requires that appserver maintainers must be able to
maintain natively-compiled Fedora packages.
b) Now that libgcj is maturing many packages are gaining Java
bindings (subversion, for example, and the databases) or whole
chunks written in Java (OpenOffice). I'd like their maintainers
to be able to add and maintain native stuff without my continued
intervention.
These two groups of maintainers have one thing in common: they don't
particularly care about gcj. Ergo, aot-compile-rpm must be simple to
use, firstly so that non-gcj people use it at all, and secondly so
that it is used correctly.
Part of "correctly" means that every installed jarfile (and only every
installed jarfile!) has a solib. This is non-trivial at the end of
%build because there are often jarfiles in the tree that are not
installed: testcases, for example, or build dependencies. If native
compilation happens at the end of %build then you have to either:
- Compile the unwanted stuff anyway, wasting time compiling it,
bandwidth transmitting it, and diskspace intalling it. This was
the major problem with find-and-aot-compile.
- List every jarfile you wanted to compile on the command line, or
list every exclusion. This places the burden of determining what's
necessary on the maintainer, and risks missing useful stuff and
compiling useless stuff. This was the major problem with both
aot-compile and katana. Even if you get it right once, upgrades
often break it silently.
There is another, less serious issue which arises from two-stage
compilation, in that jarfiles are often renamed during %install.
Both packaging and debugging are aided if the solibs have names
derived from the jarfiles they were built from. To retain this
benefit a two-step aot-compile-rpm would require command-line options
or require the files to be manually renamed. Katana had the former,
aot-compile used the latter, but both are unwieldy, basically
requiring the maintainer to state what was about to happen in
%install. This is another thing that frequently breaks on upgrades.
Hope that explains things a little better.
Cheers,
Gary
