Patch to find-and-nativify

[Robin Green]

This proposed patch makes 4 changes to the find-and-nativify in 
java-1.4.2-gcj-compat-1.4.2.0-40jpp_14rh.

- Generates a database as it goes, rather than forcing the spec file
writer to write a similar script to build the db.

- Qualifies each lib with the package name, to avoid name collisions in
Provides. (Which suggests the thought that since package names _must_ be
unique by design in rpm - isn't it then sufficient to generate libs in
%{_libdir}/%{name} instead of as %{_libdir}/%{name}/full/path/to/jar ?)

- Ignores jars which are symlinks (they might not even be in the package,
and if they are, you will end up compiling them more than once.)

- You can set the SKIPTAR environment variable to skip the tar building,
for more efficient rpm builds.

I have a handy utility script to post next which assumes some of these
changes, so I will wait to see what happens to this patch first.

[David Walluck]

Robin Green wrote:
> This proposed patch makes 4 changes to the find-and-nativify in 
> java-1.4.2-gcj-compat-1.4.2.0-40jpp_14rh.
> Generates a database as it goes, rather than forcing the spec file
>
> writer to write a similar script to build the db.

It makes sense to move the gcj-specific stuff out of the spec, but it
also makes sense to do so in a jdk-agnostic way. So, wouldn't it make
sense for find_and_nativify to be an rpm macro in jpackage-utils
/etc/rpm/macros.jpackage rather than to have it exist only in
java-1.4.2-gcj-compat? It would perhaps just define itself to `:' if the
compiler is not gcj (or if a particular package breaks when nativified).
A method is still needed in order to determine if gcj is being used.

File lists for native libs would also need to be generated so that the file list does not need to be altered when building a non-nativified rpm. (One must still be careful not to list the files twice by accident).

[Andrew Haley]

Robin Green writes:
> This proposed patch makes 4 changes to the find-and-nativify in 
> java-1.4.2-gcj-compat-1.4.2.0-40jpp_14rh.
> Generates a database as it goes, rather than forcing the spec file
>
> writer to write a similar script to build the db.
> Qualifies each lib with the package name, to avoid name collisions in
>
> Provides. (Which suggests the thought that since package names _must_ be
> unique by design in rpm - isn't it then sufficient to generate libs in
> %{_libdir}/%{name} instead of as %{_libdir}/%{name}/full/path/to/jar ?)
> Ignores jars which are symlinks (they might not even be in the package,
>
> and if they are, you will end up compiling them more than once.)
> You can set the SKIPTAR environment variable to skip the tar building,
>
> for more efficient rpm builds.
>
> I have a handy utility script to post next which assumes some of these
> changes, so I will wait to see what happens to this patch first.
>
> -- 
> Robin
>
> --- find-and-nativify.old       2005-04-10 22:28:23.000000000 +0100
> +++ find-and-nativify   2005-04-11 00:02:59.000000000 +0100
> @@ -12,20 +12,33 @@
>        (ex. eclipse)
>      BUILD_OPTIONS - a list of gcj options to pass to nativify
>        (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
> +# There's this great concept - it's called databases with no fixed size limits!

They don't have fixed size limits.
> +# For now, kludge the fixed size limit at 80000
> +gcj-dbtool -n $name.db 80000
>
> +# Use type -f to ignore symlinks
> +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
> dest_so_name=$so_dir/lib$name-`basename $jarfile`.so
> nativify $jarfile $dest_so_name "$build_options"
> gcj-dbtool -f $name.db $jarfile ${LIBDIR:-/usr/lib}/$dest_so_name

It's a lot quicker to build individual dbs and mrget them at the end.

Andrew.