On Wed, 2005-03-23 at 17:44 -0700, Tom Tromey wrote:
> >>>>> "Anthony" == Anthony Green <green@xxxxxxxxxx> writes:
>
> Anthony> Here's a real-world example from the servletapi5 spec file. It
> Anthony> currently assumes that we should be using `gcj-dbtool -p`.
> Anthony> Comments/suggestions welcome.
>
> Anthony> + # Generate native code.
> Anthony> + gcj $RPM_OPT_FLAGS -shared -findirect-dispatch -Wl,-Bsymbolic -o libjspapi-%{version}.jar.so jsr152/dist/lib/jsp-api.jar
> Anthony> + gcj-dbtool -n jspapi-%{version}.db
> [ ...]
>
> If it isn't too unwieldy, I would like to see this whole section
> replaced by a single call to some shell script to automate the
> find-compile-db loop. My goal is to make gcj-izing a jpackage RPM
> utterly trivial...
hmmm.. what do you mean by "find" in find-compile-db? I don't think
it's safe to simply compile and db-ify any .jar file in your build tree.
The best we might hope for is probably something like...
gcj-nativify -build SRC_JARFILE DEST_SO_NAME BUILD_OPTIONS
SRC_JARFILE refers to the jar file we want to process.
DEST_SO_NAME is the name we want to install it as. JPackages seem to
use different build and install jar names in some cases, so we can't
infer from SRC_JARFILE. And we should probably version the library
name.
BUILD_OPTIONS is needed because we want to pass in $RPM_OPT_FLAGS.
I suppose the script can handle certain options, like -findirect-
dispatch and -Wl,Bsymbolic.
I'm not sure I'd call this utterly trivial. Is it enough of an
improvement over what I suggested earlier?
Then we could have another little script to replace:
DB=`gcj-dbtool -p %{_libdir}`
rm -f $DB
gcj-dbtool -n $DB
(cd $DB.d; ls . | xargs gcj-dbtool -m $DB $DB)
Could these go in java-gcj-compat? Or maybe as RPM macros?
AG
