[fedora-java] Enhanced aot-compile script
Gary Benson
gbenson at redhat.com
Mon Nov 14 13:32:45 UTC 2005
Andrew Haley wrote:
> Gary Benson writes:
> > 1) Presently, rebuild-gcj-db and aot-compile-rpm _are_
> > alternatives, though not between JVMs: they're shared between
> > versions of java-1.4.2-gcj*-compat. Tom Fitzsimmons wants
> > them not to be alternatives, but to be in gcc subpackages
> > (libgcj for r-g-d, and gcc-java for a-c-r). Almost
> > incidentally, Tom pointed out that rebuild-gcj-db is so small
> > its functionality could easily be incorporated in gcj-dbtool.
>
> Right. No argument there. I have no disagreement with any of this.
> Making gcj-dbtool do the right thing is easy, and I'll do it.
Oh, ok, cool. In that case, you should know that you only need to
scan /usr/lib/gcj. rebuild-gcj-db also scans $dblocation (aka
/usr/lib/gcj-x.y.z/classmap.db.d) but that was just a workaround for
FC4 and can be removed.
> > 2) On the other hand, Fernando wants the two scripts to remain
> > alternatives, but shared between all JVMs (not just GCJ ones).
> > My opinion is that something like this would be a good idea,
> > but that acquiring the GCJ-specific command names for it is
> > the wrong thing to do (not least because GCJ's database should
> > be rebuilt whenever an rpm with GCJ-precompiled stuff is
> > installed regardless of what JVM alternative is in force).
>
> This is the issue that I am addressing.
>
> My suggestion solves this problem:
>
> > GCJ's database should be rebuilt whenever an rpm with
> > GCJ-precompiled stuff is installed regardless of what JVM
> > alternative is in force
>
> ... without penalizing users who aren't installing gcj packages. It
> also abstracts away from the RPM specfiles the nitpicky gcj details.
> This is better than having "gcj-dbtool --rebuild" or its equivalent
> in each specfile.
When will it be invoked if not in every specfile?
Cheers,
Gary
More information about the fedora-devel-java-list
mailing list