Updated patch to find-and-aot-compile (formerly find-and-nativify)

[Robin Green]

This patch to find-and-aot-compile incorporates previous suggestions (see
previous thread "Patch to find-and-nativify").

In particular, instead of replicating the directory structure of the jars,
it just stores the shlibs in one directory, because I can't see a
realistic scenario where having the full directory structure would be
necessary. The decision is a matter of personal taste AFAICS. (Sane
packages should not contain two jars with the exact same basenames but
different contents.)

[Andrew Haley]

Robin Green writes:
> This patch to find-and-aot-compile incorporates previous suggestions (see
> previous thread "Patch to find-and-nativify").
>
> In particular, instead of replicating the directory structure of the jars,
> it just stores the shlibs in one directory, because I can't see a
> realistic scenario where having the full directory structure would be
> necessary. The decision is a matter of personal taste AFAICS. (Sane
> packages should not contain two jars with the exact same basenames but
> different contents.)

Why not?  Some packages are amalgamations of other packages whose
maintainers don't maintain a unique namespace for jars.

Andrew.

[Andrew Overholt]

* Robin Green  [2005-05-08 08:16]:
> In particular, instead of replicating the directory structure of the jars,
> it just stores the shlibs in one directory, because I can't see a
> realistic scenario where having the full directory structure would be
> necessary.

Eclipse contains multiple jars with the same name.  That's the reason that
I originally kept the directory structure for the native libs.

Andrew

[Robin Green]

On Sun, 08 May 2005 13:55:23 -0400, Andrew Overholt wrote:
> > In particular, instead of replicating the directory structure of the jars,
> > it just stores the shlibs in one directory, because I can't see a
> > realistic scenario where having the full directory structure would be
> > necessary.
>
> Eclipse contains multiple jars with the same name.  That's the reason that
> I originally kept the directory structure for the native libs.

OK, that's easily fixed. Here's the updated patch. By the way, this
assumes the new aot-compile script posted by Gary Benson on 22 Apr 2005.

--- find-and-aot-compile.orig	2005-05-08 13:08:01.000000000 +0100
+++ find-and-aot-compile	2005-05-24 18:25:32.000000000 +0100
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/bash -p
 # find-and-aot-compile

: ${1?"
@@ -12,20 +12,34 @@
       (ex. eclipse)
     BUILD_OPTIONS - a list of gcj options to pass to aot-compile
       (outside of -findirect-dispatch, -shared, and -Wl,-Bsymbolic)
+      
+  By default, the generated database will assume libraries will go in /usr/lib.
+  To change this, set LIBDIR to the appropriate directory.
+ 
+  Set SKIPTAR=y to skip tar file creation.
 "}

name=$1
 build_options=$2

-for jarfile in $(find -name *.jar); do
+rm -f dblist
+
+for jarfile in $(find -type f -name *.jar); do
     # This is ugly.  What we want is to be able to natively-compile all the
     # jars within an RPM build tree as well as from an arbitrary location
     # in the filesystem.  Patches welcome :)
-    so_dir="./$name/$(dirname $jarfile | \
-      sed 's:^.+/::')";
-    mkdir -p $so_dir;
-    dest_so_name=$so_dir/lib`basename $jarfile`.so
-    aot-compile $jarfile $dest_so_name "$build_options"
+    aot-compile "$build_options" $jarfile
+    built_so_name="`dirname $jarfile`/lib`basename $jarfile`.so"
+    dest_so_name="$name/$built_so_name"
+    mkdir -p "$name/`dirname $jarfile`"
+    mv "$built_so_name" "$dest_so_name"
+    dbfile="$jarfile.db"
+    gcj-dbtool -f "$dbfile" "$jarfile" "${LIBDIR:-/usr/lib}/$dest_so_name"
+    printf "$dbfile\0" >>dblist
 done

-tar czf $name.tar.gz $name
+gcj-dbtool -0 -m $name.db <dblist
+
+if [ -z "{$SKIPTAR:-}" ]; then
+  tar czf $name.tar.gz $name
+fi