Patch: Remove fastjar

Patch: Remove fastjar

[Tom Tromey]

This removes fastjar from the tree, as requested by the GCC SC.

In order to build libjava, you will now need an external 'jar'
executable; libjava/configure will search for 'jar' and 'fastjar'.

fastjar doesn't have a home yet.  It was rejected from savannah
because fastjar.texi is GPL and not GFDL.  Most likely I will import
fastjar into the rhug repository on sourceware.org (and then fix it up
to actually build).  In any case I don't think this issue should
affect whether or not this patch is committed.

I didn't include the generated diffs or the diff which actually
removes the fastjar directory.

Built on x86 FC4.  Ok for trunk?

Tom

:ADDPATCH build:

2006-03-30  Tom Tromey  <tromey@redhat.com>

	* Makefile.def: Removed all mention of fastjar.
	* Makefile.tpl: Removed all mention of fastjar.

2006-03-30  Tom Tromey  <tromey@redhat.com>

	* Makefile.in: Rebuilt.
	* Makefile.am (ZIP): Removed.
	(libgcj-$(gcc_version).jar): Use $(JAR).
	(src.zip): Likewise.
	* configure: Rebuilt.
	* configure.ac: Check for jar.  Removed code to set ZIP.
 
Index: Makefile.def
===================================================================
--- Makefile.def	(revision 112544)
+++ Makefile.def	(working copy)
@@ -47,7 +47,6 @@
 host_modules= { module= diff; };
 host_modules= { module= dosutils; no_check= true; };
 host_modules= { module= etc; };
-host_modules= { module= fastjar; no_check_cross= true; };
 host_modules= { module= fileutils; };
 host_modules= { module= findutils; };
 host_modules= { module= find; };
@@ -378,11 +377,6 @@
 dependencies = { module=all-sim; on=all-readline; };
 dependencies = { module=all-sim; on=configure-gdb; };
 
-// Other host modules.
-dependencies = { module=all-fastjar; on=all-zlib; };
-dependencies = { module=all-fastjar; on=all-build-texinfo; };
-dependencies = { module=all-fastjar; on=all-libiberty; };
-
 // Warning, these are not well tested.
 dependencies = { module=all-autoconf; on=all-m4; };
 dependencies = { module=all-autoconf; on=all-build-texinfo; };
@@ -433,14 +427,10 @@
 lang_env_dependencies = { module=zlib; };
 
 dependencies = { module=configure-target-boehm-gc; on=configure-target-qthreads; };
-dependencies = { module=configure-target-fastjar; on=configure-target-zlib; };
-dependencies = { module=all-target-fastjar; on=all-target-zlib; };
-dependencies = { module=all-target-fastjar; on=all-target-libiberty; };
 dependencies = { module=configure-target-libjava; on=configure-target-zlib; };
 dependencies = { module=configure-target-libjava; on=configure-target-boehm-gc; };
 dependencies = { module=configure-target-libjava; on=configure-target-qthreads; };
 dependencies = { module=configure-target-libjava; on=configure-target-libffi; };
-dependencies = { module=all-target-libjava; on=all-fastjar; };
 dependencies = { module=all-target-libjava; on=all-target-zlib; };
 dependencies = { module=all-target-libjava; on=all-target-boehm-gc; };
 dependencies = { module=all-target-libjava; on=all-target-qthreads; };
Index: Makefile.tpl
===================================================================
--- Makefile.tpl	(revision 112544)
+++ Makefile.tpl	(working copy)
@@ -567,7 +567,7 @@
 	-rm -f texinfo/doc/Makefile texinfo/po/POTFILES
 	-rmdir texinfo/doc texinfo/info texinfo/intl texinfo/lib 2>/dev/null
 	-rmdir texinfo/makeinfo texinfo/po texinfo/util 2>/dev/null
-	-rmdir fastjar gcc libiberty texinfo zlib 2>/dev/null
+	-rmdir gcc libiberty texinfo zlib 2>/dev/null
 
 local-maintainer-clean:
 	@echo "This command is intended for maintainers to use;"
Index: libjava/configure.ac
===================================================================
--- libjava/configure.ac	(revision 112544)
+++ libjava/configure.ac	(working copy)
@@ -116,6 +116,10 @@
 AC_CHECK_TOOL(LD, ld)
 AC_CHECK_TOOL(AR, ar)
 AC_CHECK_TOOL(RANLIB, ranlib, :)
+AC_CHECK_PROGS(JAR, [jar fastjar], false)
+if test "$JAR" = false; then
+  AC_MSG_ERROR(jar program not found)
+fi
 
 AC_PROG_INSTALL
 
@@ -289,7 +293,6 @@
    built)
       GCJ="$built_gcc_dir/gcj -B`${PWDCMD-pwd}`/ -B$built_gcc_dir/"
       GCJH='$(top_builddir)/$(MULTIBUILDTOP)../../$(host_subdir)/gcc/gcjh'
-      ZIP='$(top_builddir)/$(MULTIBUILDTOP)../../$(host_subdir)/fastjar/fastjar'
    ;;
    cross)
       if test "x${with_newlib}" = "xyes"; then
@@ -299,20 +302,15 @@
       else
          GCJ="${target_noncanonical}-gcj -B`${PWDCMD-pwd}`/"
       fi
-      ZIP='$(target_noncanonical)-fastjar'
       GCJH='$(target_noncanonical)-gcjh'
    ;;
    path)
       GCJ="gcj -B`${PWDCMD-pwd}`/"
-      ## In this case, gcj is found outside the build tree.  However, zip is
-      ## found in the build tree.
-      ZIP='$(top_builddir)/$(MULTIBUILDTOP)../$(COMPPATH)/fastjar/fastjar'
       GCJH=gcjh
    ;;
 esac
 
 AC_SUBST(GCJH)
-AC_SUBST(ZIP)
 
 # Create it, so that compile/link tests don't fail
 test -f libgcj.spec || touch libgcj.spec
Index: libjava/Makefile.am
===================================================================
--- libjava/Makefile.am	(revision 112544)
+++ libjava/Makefile.am	(working copy)
@@ -87,7 +87,6 @@
 ##
 
 GCJH = @GCJH@
-ZIP = @ZIP@
 
 ## The compiler with whatever flags we want for both -c and -C
 ## compiles.
@@ -322,10 +321,7 @@
 	$(LTGCJCOMPILE) -o $@ -c $< -Wc,--resource,$(@:.lo=)
 
 libgcj-$(gcc_version).jar:
-	jardir=`dirname $(ZIP)`; \
-	jardir=`cd $$jardir && pwd`; \
-	jarname=`basename $(ZIP)`; \
-	cd classpath/lib; $$jardir/$$jarname -cfM \
+	cd classpath/lib; $(JAR) -cfM \
 	    ../../libgcj-$(gcc_version).jar gnu java javax org
 
 CLEANFILES = libgcj-$(gcc_version).jar \
@@ -883,9 +879,10 @@
 	    echo $$file; \
 	  done ); \
 	) | \
-## Many of the above circumlocutions are because ZIP will most likely
-## be a relative path to fastjar.
-	$(ZIP) -cfM@ $$here/src.zip
+## Many of the above circumlocutions were because ZIP used to be a
+## relative path to fastjar.  It didn't seem worthwhile to change the
+## code when we moved to an external jar.
+	$(JAR) -cfM@ $$here/src.zip
 ## Override GNU Classpath sources with libgcj replacements.
 	here=`pwd`; \
 	( \
@@ -897,7 +894,7 @@
 	    echo $$file; \
 	  done ); \
 	) | \
-	$(ZIP) -ufM@ $$here/src.zip
+	$(JAR) -ufM@ $$here/src.zip
 
 ## We use a variable for this in case the user wants to override it.
 sourcesdir = $(jardir)

Re: Patch: Remove fastjar

[Andrew Pinski]

> 
> This removes fastjar from the tree, as requested by the GCC SC.
> 
> In order to build libjava, you will now need an external 'jar'
> executable; libjava/configure will search for 'jar' and 'fastjar'.
> 
> fastjar doesn't have a home yet.  It was rejected from savannah
> because fastjar.texi is GPL and not GFDL.  Most likely I will import
> fastjar into the rhug repository on sourceware.org (and then fix it up
> to actually build).  In any case I don't think this issue should
> affect whether or not this patch is committed.
> 
> I didn't include the generated diffs or the diff which actually
> removes the fastjar directory.
> 
> Built on x86 FC4.  Ok for trunk?


Is there a reason why you are removing support from building
fastjar inside the tree?

There is support for building bash in there already and it would
be nice if you kept support for building fastjar also.  Maybe even
later on using svn:externs so that fastjar could be still "part" of
GCC sources.  It is a bit strange to remove a requirement to build
part of GCC without documenting this new requirement.  

Also wasn't there talk about pulling GMP into the tree so that gfortran
and GCC could use it without an additional requirement?  If so isn't
that the same situtation as fastjar?

Thanks,
Andrew Pinski

Re: Patch: Remove fastjar

[David Daney]

Tom Tromey wrote:
> This removes fastjar from the tree, as requested by the GCC SC.
> 
> In order to build libjava, you will now need an external 'jar'
> executable; libjava/configure will search for 'jar' and 'fastjar'.
> 
> fastjar doesn't have a home yet.  It was rejected from savannah
> because fastjar.texi is GPL and not GFDL.  Most likely I will import
> fastjar into the rhug repository on sourceware.org (and then fix it up
> to actually build).  In any case I don't think this issue should
> affect whether or not this patch is committed.
> 
> I didn't include the generated diffs or the diff which actually
> removes the fastjar directory.
> 
> Built on x86 FC4.  Ok for trunk?
> 
> Tom
> 
> :ADDPATCH build:
> 
> 2006-03-30  Tom Tromey  <tromey@redhat.com>
> 
> 	* Makefile.def: Removed all mention of fastjar.
> 	* Makefile.tpl: Removed all mention of fastjar.
> 
> 2006-03-30  Tom Tromey  <tromey@redhat.com>
> 
> 	* Makefile.in: Rebuilt.
> 	* Makefile.am (ZIP): Removed.
> 	(libgcj-$(gcc_version).jar): Use $(JAR).
> 	(src.zip): Likewise.
> 	* configure: Rebuilt.
> 	* configure.ac: Check for jar.  Removed code to set ZIP.
>  

Perhaps gcc/doc/install.texi should have something added to reflect the 
new requirements for building.

David Daney.

Re: Patch: Remove fastjar

[Andrew Pinski]

> Perhaps gcc/doc/install.texi should have something added to reflect the 
> new requirements for building.

I still say there is a misunderstanding going on because not all
people will already have a jar program installed (in fact I don't
one installed on my work GNU/Linux box).  Making a new requirment
to compile libgcj will make GCC people think twice about compiling
GCC.


-- Pinski

Re: Patch: Remove fastjar

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 886 bytes --]

On Thu, 2006-03-30 at 18:29 -0500, Andrew Pinski wrote:
> > Perhaps gcc/doc/install.texi should have something added to reflect the 
> > new requirements for building.
> 
> I still say there is a misunderstanding going on because not all
> people will already have a jar program installed (in fact I don't
> one installed on my work GNU/Linux box).  Making a new requirment
> to compile libgcj will make GCC people think twice about compiling
> GCC.

It is going to be a bit of extra pain for users to compile libgcj if
this is removed from the tree. Would it be possible to use the minizip
implementation from the included zlib to create the jar/zip file? That
way we don't introduce an extra dependency on the user. Or try to detect
a working zip binary on the users system? At least a zip utility is more
likely to be available then a jar utility.

Cheers,

Mark

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: Patch: Remove fastjar

[Per Bothner]

Mark Wielaard wrote:
> On Thu, 2006-03-30 at 18:29 -0500, Andrew Pinski wrote:
>>> Perhaps gcc/doc/install.texi should have something added to reflect the 
>>> new requirements for building.
>> I still say there is a misunderstanding going on because not all
>> people will already have a jar program installed (in fact I don't
>> one installed on my work GNU/Linux box).  Making a new requirment
>> to compile libgcj will make GCC people think twice about compiling
>> GCC.
> 
> It is going to be a bit of extra pain for users to compile libgcj if
> this is removed from the tree. Would it be possible to use the minizip
> implementation from the included zlib to create the jar/zip file? That
> way we don't introduce an extra dependency on the user. Or try to detect
> a working zip binary on the users system? At least a zip utility is more
> likely to be available then a jar utility.

Ideally, I'd like to get rid of fastjar.  It should be replaced by a
wrapper on top of java.util.zip and java.util.jar.  I assume this is
what Sun does.  Is there any reason to not do that?

For bootstrapping, we can use zip/unzip if an installed jar isn't
available.  Though I'm not sure why we need either.

One factor is that jar/fastjar is a host application, while we build
libgcj for target.  I don't think that's a problem: Part of the
bootstrap process when building a cross-compiler could reasonably
be to build host versions of the libraries.   We used to do this
for libiberty; I don't know what we currently do.  Presumably
this is not a problem at this point - gcjx would obviously need C++
host libraries.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: Patch: Remove fastjar

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 2025 bytes --]

Hi Per,

On Thu, 2006-03-30 at 16:29 -0800, Per Bothner wrote:
> Mark Wielaard wrote:
> > On Thu, 2006-03-30 at 18:29 -0500, Andrew Pinski wrote:
> >>> Perhaps gcc/doc/install.texi should have something added to reflect the 
> >>> new requirements for building.
> >> I still say there is a misunderstanding going on because not all
> >> people will already have a jar program installed (in fact I don't
> >> one installed on my work GNU/Linux box).  Making a new requirment
> >> to compile libgcj will make GCC people think twice about compiling
> >> GCC.
> > 
> > It is going to be a bit of extra pain for users to compile libgcj if
> > this is removed from the tree. Would it be possible to use the minizip
> > implementation from the included zlib to create the jar/zip file? That
> > way we don't introduce an extra dependency on the user. Or try to detect
> > a working zip binary on the users system? At least a zip utility is more
> > likely to be available then a jar utility.
> 
> Ideally, I'd like to get rid of fastjar.  It should be replaced by a
> wrapper on top of java.util.zip and java.util.jar.  I assume this is
> what Sun does.  Is there any reason to not do that?

Theoretically not. It would make bootstrapping things a bit more
interesting. But as you said those things can be done with some careful
thought about what gets build when/where and depends on what. The real
reason we don't have such a gjar wrapper based on the libgcj/classpath
util.jar package itself is that there was no practical need because we
already have fastjar. Raif wrote a jarsigner tool for GNU Classpath just
recently, that could be a base for such a gjar tool. But I am not really
convinced that ripping out fastjar to force someone to write such a
replacement to include in the gcc source tree is a very productive. On
the other hand it is probably just a couple of days of work, so if that
really makes everybody happy and gets us forward again then please go
for it!

Cheers,

Mark

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

[RFC] jar shell script (was Re: Patch: Remove fastjar)

[Paolo Bonzini]

[-- Attachment #1: Type: text/plain, Size: 308 bytes --]

> I agree that using zip, or even better zlib's minizip (zlib is built for 
> the host), can be a very good solution for bootstrapping.  Another 
> possibility would be to write "jar" as a shell script wrapper around zip 
> or minizip.  I'm sure that's possible.

Like this (mostly untested) script.

Paolo


[-- Attachment #2: bashjar --]
[-- Type: text/plain, Size: 9178 bytes --]

#! /bin/sh
# Copyright (C) 2006  Free Software Foundation
# Written by Paolo Bonzini.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published
# by the Free Software Foundation; either version 2 of the License,
# or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
# or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
# for more details.
#
# You should have received a copy of the GNU General Public License along
# with this program; if not, write to the Free Software Foundation, Inc.,
# 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.

: ${ZIP=zip}
: ${UNZIP=unzip}
progname="$0"

# Emit a usage message and exit with error status 1
usage () {
  cat >&2 <<EOF
Usage: $0 {ctxu}[vfm0Mi] [jar-file] [manifest-file] [-C dir] files ...
Options:
    -c  create new archive
    -t  list table of contents for archive
    -x  extract named (or all) files from archive
    -u  update existing archive
    -v  generate verbose output on standard output
    -f  specify archive file name
    -m  include manifest information from specified manifest file
    -0  store only; use no ZIP compression
    -M  do not create a manifest file for the entries
    -i  generate index information for the specified jar files
    -C  change to the specified directory and include the following file
If any file is a directory then it is processed recursively.
The manifest file name and the archive file name needs to be specified
in the same order the 'm' and 'f' flags are specified.

Example 1: to archive two class files into an archive called classes.jar: 
       jar cvf classes.jar Foo.class Bar.class 
Example 2: use an existing manifest file 'mymanifest' and archive all the
           files in the foo/ directory into 'classes.jar': 
       jar cvfm classes.jar mymanifest -C foo/ .

EOF
  exit 1
}

# Emit an error message and exit with error status 1
error () {
  echo "$progname: $*" >&2
  exit 1
}

# Make a temporary directory and store its name in the JARTMP variable.
make_tmp () {
  JARTMPSUFF=$$
  test -z "$RANDOM" && RANDOM=7654
  while :; do
    JARTMP=/tmp/tmp-jar.$JARTMPSUFF
    $mkdir_p $JARTMP 2>&1 && break
    JARTMPSUFF=`expr \( $JARTMPSUFF + $RANDOM \) % 32768`
  done

  trap 'rm -rf "$JARTMP"'
}

# Usage: make_manifest destfile kind [source-manifest]
# Create a manifest file and store it in destfile.  KIND can be auto or user,
# in which case SOURCE-MANIFEST must be specified as well.
make_manifest () {
  $mkdir_p `dirname "$1"`
  case $2 in
    auto)
      cat > "$1" <<\EOF
Manifest-Version: 1.0
Created-By: @VERSION@

EOF
      ;;
    user)
      cp "$3" "$1"
      ;;
  esac
}

# Usage: set_var var [value]
# Exit with an error if set_var was already called for the same VAR.  Else
# set the variable VAR to the value VALUE (or the empty value if no parameter
# is given).
set_var () {
  if eval test x\$set_$1 = xset; then
    error Incompatible or repeated options.
  else
    eval $1='"$2"'
    eval set_$1=set
  fi
}

# Process the arguments, including -C options, and copy the whole tree
# to $JARTMP/files so that zip can be invoked later from there.
make_files () {
  for arg
  do
    if $change; then
      change=false
      cd "$arg" || exit 1
      continue
    fi
    case "$arg" in
      -C)
	change=:
	;;
      -C*)
	cd "`expr $arg : '-C\(.*\)' `"
	;;
      *)
	if test -f "$arg"; then
	  $mkdir_p $JARTMP/files/`dirname "$arg"`
	  ln "$arg" $JARTMP/files/"$arg" || cp "$arg" $JARTMP/files/"$arg"
	elif test -d "$arg"; then
	  find "$arg" | while read file; do
	    if test -f "$arg"; then
	      ln "$arg" $JARTMP/files/"$arg" || cp "$arg" $JARTMP/files/"$arg"
	    elif test -d "$file"; then
	      $mkdir_p $JARTMP/files/"$file"
	    else
	      error "$arg": Invalid file type.
	    fi
	  done
	else
	  error "$arg": Invalid file type.
	fi
	;;
    esac
  done
}

# Same as "jar tf $1".
jar_list () {
  $UNZIP -l "$1" | \
    sed '1,/^ ----/d;/^ ----/,$d;s/^ *[0-9]*  ..-..-.. ..:..   //'
}

# Same as "jar tvf $1".
jar_list_verbose () {
  $UNZIP -l "$1" | \
    awk 'BEGIN { yes = 0 }
	 /^ ----/ { yes = !yes; next }
	 yes {
	   size=$1
	   split ($2, d, "-")
	   split ($3, t, ":")
	   d[3] += (d[3] < 80) ? 2000 : 1900
	   timestamp=d[3] " " d[2] " " d[1] " " t[1] " " t[2] " 00"
	   gsub (/^ *[0-9]*  ..-..-.. ..:..   /, "")
	   printf "%6d %s %s\n", size, strftime ("%+", mktime (timestamp)), $0
	 }'
}

# mkdir -p emulation based on the mkinstalldirs script.
mkdir_p ()
{
  for file
  do
    case $file in
      /*) pathcomp=/ ;;
      *)  pathcomp= ;;
    esac
    oIFS=$IFS
    IFS=/
    set fnord $file
    shift
    IFS=$oIFS

    for d
    do
      test "x$d" = x && continue
      pathcomp=$pathcomp$d
      case $pathcomp in
        -*) pathcomp=./$pathcomp ;;
      esac

      if test ! -d "$pathcomp"; then
        mkdir "$pathcomp" || lasterr=$?
        if test ! -d "$pathcomp"; then
          errstatus=$lasterr
        fi
      fi
      pathcomp=$pathcomp/
    done
  done
}

# Detect mkdir -p
# On NextStep and OpenStep, the `mkdir' command does not
# recognize any option.  It will interpret all options as
# directories to create, and then abort because `.' already
# exists.
if mkdir -p --version . >/dev/null 2>&1 && test ! -d ./--version; then
  mkdir_p='mkdir -p'
else
  mkdir_p='mkdir_p'
  test -d ./-p && rmdir ./-p
  test -d ./--version && rmdir ./--version
fi

# Process the first command line option.
case "$1" in
  -*) commands=`echo X"$1" | sed 's/^X-//' ` ;;
  *) commands="$1"
esac

shift
mode=unknown
cur_dir=.
jarfile=
manifest_kind=auto
store=
verbose=false
outredirect=:
while test -n "$commands"; do
  command=`expr "$commands" : '\(.\)'`
  commands=`expr "$commands" : '.\(.*\)'`
  case "$command" in
    c)
      set_var mode create
      ;;
    t)
      set_var mode list
      ;;
    x)
      set_var mode extract
      ;;
    u)
      set_var mode update
      ;;
    f)
      test $# = 0 && usage
      # Multiple -f options are accepted by Sun's JAR tool.
      jarfile="$1"
      shift
      ;;
    m)
      test $# = 0 && usage
      test "$manifest_kind" = auto && manifest_kind=user
      # Multiple -f options are accepted by Sun's JAR tool.
      manifest_file="$1"
      shift
      ;;
    0)
      store=-0
      ;;
    v)
      verbose=:
      ;;
    M)
      manifest_kind=none
      ;;
    i)
      set_var mode index
      ;;
    C)
      test $# = 0 && usage
      cur_dir="$1"
      shift
      ;;
    *)
      usage ;;
  esac
done

case "$jarfile" in
  "")
    make_tmp
    $mkdir_p $JARTMP/out
    jarfile=$JARTMP/out/tmp-stdin.jar
    out_redirect='exec >&2'
    case $mode in
      update|extract|list) cat > $JARTMP/out/tmp-stdin.jar ;;
    esac
    ;;
  */*)
    dir=`dirname "$jarfile"`
    jarfile=`cd $dir && pwd`/`basename "$jarfile"`
    ;;
  *)
    dir=`pwd`
    jarfile=`pwd`/`basename "$jarfile"`
    ;;
esac

# Perform a -C option if given right away.
cd "$cur_dir"

case $mode in
  unknown)
    usage
    ;;

  extract)
    make_tmp
    jar_list "$jarfile" > $JARTMP/list
    test "$#" = 0 && cp $JARTMP/list $JARTMP/chosen
    for arg
    do
      $skip && skip=false && continue
      case "$arg" in
	-C) skip=: ;;
	-C*) ;;
	*)
	  escaped=`echo "$arg" | sed -n 's/[][.^$\*]/\\&/' `
	  grep -e "^list/" >> $JARTMP/chosen
	  grep -e "^list$" >> $JARTMP/chosen
      esac
    done
    if $verbose; then
      sort < $JARTMP/chosen | uniq | xargs $UNZIP -o "$jarfile" | \
	sed -ne 's/^   creating/  created/p' -e 's/^  inflating/extracted/p'
    else
      sort < $JARTMP/chosen | uniq | xargs $UNZIP -o "$jarfile" > /dev/null
    fi
    ;;

  create)
    make_tmp
    $mkdir_p $JARTMP/out
    $mkdir_p $JARTMP/files
    tmp_jarfile=$JARTMP/out/`basename "$jarfile"`
    make_files "$@"
    if test $manifest_kind != none; then
      make_manifest $JARTMP/files/META-INF/MANIFEST.MF $manifest_kind $manifest_file
    fi
    if $verbose; then
      (eval $out_redirect; cd $JARTMP/files && $ZIP -rv "$tmp_jarfile" $store .)
    else
      (cd $JARTMP/files && $ZIP -r "$tmp_jarfile" $store . > /dev/null)
    fi
    mv "$tmp_jarfile" "$jarfile"
    ;;

  update)
    make_tmp
    $mkdir_p $JARTMP/files
    make_files "$@"
    case $manifest_kind in
      none)
	$verbose && (eval $out_redirect; echo removing manifest)
	$ZIP -d "$jarfile" META-INF/MANIFEST.MF > /dev/null
	;;
      *)
	make_manifest $JARTMP/files/META-INF/MANIFEST.MF $manifest_kind $manifest_file
	;;
    esac
    if $verbose; then
      (eval $out_redirect; cd $JARTMP/files && $ZIP -urv "$jarfile" $store .)
    else
      (cd $JARTMP/files && $ZIP -ur "$jarfile" $store . > /dev/null)
    fi
    ;;

  list)
    if $verbose; then
      jar_list_verbose "$jarfile"
    else
      jar_list "$jarfile"
    fi ;;

  index)
    ;;
esac

EXITCODE=$?
if test $EXITCODE = 0 && \
   test -n $JARTMP && test "$jarfile" = $JARTMP/out/tmp-stdin.jar; then
  case $mode in
    create|update) cat $JARTMP/out/tmp-stdin.jar ;;
  esac
fi
exit $EXITCODE

Re: [RFC] jar shell script (was Re: Patch: Remove fastjar)

[Paolo Bonzini]

[-- Attachment #1: Type: text/plain, Size: 411 bytes --]

Paolo Bonzini wrote:
>> I agree that using zip, or even better zlib's minizip (zlib is built 
>> for the host), can be a very good solution for bootstrapping.  Another 
>> possibility would be to write "jar" as a shell script wrapper around 
>> zip or minizip.  I'm sure that's possible.
> 
> Like this (mostly untested) script.

Or more like this, for which I tested creation and not only extraction...

Paolo

[-- Attachment #2: bashjar --]
[-- Type: text/plain, Size: 9440 bytes --]

#! /bin/sh
# Copyright (C) 2006  Free Software Foundation
# Written by Paolo Bonzini.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published
# by the Free Software Foundation; either version 2 of the License,
# or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
# or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
# for more details.
#
# You should have received a copy of the GNU General Public License along
# with this program; if not, write to the Free Software Foundation, Inc.,
# 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.

: ${ZIP=zip}
: ${UNZIP=unzip}
progname="$0"

# Emit a usage message and exit with error status 1
usage () {
  cat >&2 <<EOF
Usage: $0 {ctxu}[vfm0Mi] [jar-file] [manifest-file] [-C dir] files ...
Options:
    -c  create new archive
    -t  list table of contents for archive
    -x  extract named (or all) files from archive
    -u  update existing archive
    -v  generate verbose output on standard output
    -f  specify archive file name
    -m  include manifest information from specified manifest file
    -0  store only; use no ZIP compression
    -M  do not create a manifest file for the entries
    -i  generate index information for the specified jar files
    -C  change to the specified directory and include the following file
If any file is a directory then it is processed recursively.
The manifest file name and the archive file name needs to be specified
in the same order the 'm' and 'f' flags are specified.

Example 1: to archive two class files into an archive called classes.jar: 
       jar cvf classes.jar Foo.class Bar.class 
Example 2: use an existing manifest file 'mymanifest' and archive all the
           files in the foo/ directory into 'classes.jar': 
       jar cvfm classes.jar mymanifest -C foo/ .

EOF
  exit 1
}

# Emit an error message and exit with error status 1
error () {
  echo "$progname: $*" >&2
  exit 1
}

# Make a temporary directory and store its name in the JARTMP variable.
make_tmp () {
  if test -z "$JARTMP"; then
    JARTMPSUFF=$$
    test -z "$RANDOM" && RANDOM=7654
    while :; do
      JARTMP=/tmp/tmp-jar.$JARTMPSUFF
      $mkdir_p $JARTMP 2>&1 && break
      JARTMPSUFF=`expr \( $JARTMPSUFF + $RANDOM \) % 32768`
    done

    trap 'rm -rf "$JARTMP"'
  fi
}

# Usage: make_manifest destfile kind [source-manifest]
# Create a manifest file and store it in destfile.  KIND can be auto or user,
# in which case SOURCE-MANIFEST must be specified as well.
make_manifest () {
  $mkdir_p `dirname "$1"`
  case $2 in
    auto)
      cat > "$1" <<\EOF
Manifest-Version: 1.0
Created-By: @VERSION@

EOF
      ;;
    user)
      cp "$3" "$1"
      ;;
  esac
}

# Usage: set_var var [value]
# Exit with an error if set_var was already called for the same VAR.  Else
# set the variable VAR to the value VALUE (or the empty value if no parameter
# is given).
set_var () {
  if eval test x\$set_$1 = xset; then
    error Incompatible or repeated options.
  else
    eval $1='"$2"'
    eval set_$1=set
  fi
}

# Process the arguments, including -C options, and copy the whole tree
# to $JARTMP/files so that zip can be invoked later from there.
make_files () {
  change=false
  for arg
  do
    if $change; then
      change=false
      cd "$arg" || exit 1
      continue
    fi
    case "$arg" in
      -C)
	change=:
	;;
      -C*)
	cd "`expr $arg : '-C\(.*\)' `"
	;;
      *)
	if test -f "$arg"; then
	  $mkdir_p "$JARTMP"/files/`dirname "$arg"`
	  ln "$arg" "$JARTMP"/files/"$arg" || cp "$arg" "$JARTMP"/files/"$arg"
	elif test -d "$arg"; then
	  find "$arg" | while read file; do
	    if test -f "$file"; then
	      ln "$file" "$JARTMP"/files/"$file" || cp "$file" "$JARTMP"/files/"$file"
	    elif test -d "$file"; then
	      $mkdir_p "$JARTMP"/files/"$file"
	    else
	      error "$arg": Invalid file type.
	    fi
	  done
	elif test -e "$arg"; then
	  error "$arg": Invalid file type.
	else
	  error "$arg": File not found.
	fi
	;;
    esac
  done
}

# Same as "jar tf $1".
jar_list () {
  $UNZIP -l "$1" | \
    sed '1,/^ ----/d;/^ ----/,$d;s/^ *[0-9]*  ..-..-.. ..:..   //'
}

# Same as "jar tvf $1".
jar_list_verbose () {
  $UNZIP -l "$1" | \
    awk 'BEGIN { yes = 0 }
	 /^ ----/ { yes = !yes; next }
	 yes {
	   size=$1
	   split ($2, d, "-")
	   split ($3, t, ":")
	   d[3] += (d[3] < 80) ? 2000 : 1900
	   timestamp=d[3] " " d[2] " " d[1] " " t[1] " " t[2] " 00"
	   gsub (/^ *[0-9]*  ..-..-.. ..:..   /, "")
	   printf "%6d %s %s\n", size, strftime ("%+", mktime (timestamp)), $0
	 }'
}

# mkdir -p emulation based on the mkinstalldirs script.
mkdir_p ()
{
  for file
  do
    case $file in
      /*) pathcomp=/ ;;
      *)  pathcomp= ;;
    esac
    oIFS=$IFS
    IFS=/
    set fnord $file
    shift
    IFS=$oIFS

    for d
    do
      test "x$d" = x && continue
      pathcomp=$pathcomp$d
      case $pathcomp in
        -*) pathcomp=./$pathcomp ;;
      esac

      if test ! -d "$pathcomp"; then
        mkdir "$pathcomp" || lasterr=$?
        if test ! -d "$pathcomp"; then
          errstatus=$lasterr
        fi
      fi
      pathcomp=$pathcomp/
    done
  done
}

# Detect mkdir -p
# On NextStep and OpenStep, the `mkdir' command does not
# recognize any option.  It will interpret all options as
# directories to create, and then abort because `.' already
# exists.
if mkdir -p --version . >/dev/null 2>&1 && test ! -d ./--version; then
  mkdir_p='mkdir -p'
else
  mkdir_p='mkdir_p'
  test -d ./-p && rmdir ./-p
  test -d ./--version && rmdir ./--version
fi

# Process the first command line option.
case "$1" in
  -*) commands=`echo X"$1" | sed 's/^X-//' ` ;;
  *) commands="$1"
esac

shift
mode=unknown
cur_dir=.
jarfile=
manifest_kind=auto
store=
verbose=false
outredirect=:
while test -n "$commands"; do
  command=`expr "$commands" : '\(.\)'`
  commands=`expr "$commands" : '.\(.*\)'`
  case "$command" in
    c)
      set_var mode create
      ;;
    t)
      set_var mode list
      ;;
    x)
      set_var mode extract
      ;;
    u)
      set_var mode update
      ;;
    f)
      test $# = 0 && usage
      # Multiple -f options are accepted by Sun's JAR tool.
      jarfile="$1"
      shift
      ;;
    m)
      test $# = 0 && usage
      test "$manifest_kind" = auto && manifest_kind=user
      # Multiple -f options are accepted by Sun's JAR tool.
      manifest_file="$1"
      shift
      ;;
    0)
      store=-0
      ;;
    v)
      verbose=:
      ;;
    M)
      manifest_kind=none
      ;;
    i)
      set_var mode index
      ;;
    C)
      test $# = 0 && usage
      cur_dir="$1"
      shift
      ;;
    *)
      usage ;;
  esac
done

case "$jarfile" in
  "")
    make_tmp
    $mkdir_p "$JARTMP"/out
    jarfile="$JARTMP"/out/tmp-stdin.jar
    out_redirect='exec >&2'
    case $mode in
      update|extract|list) cat > "$JARTMP"/out/tmp-stdin.jar ;;
    esac
    ;;
  */*)
    dir=`dirname "$jarfile"`
    jarfile=`cd $dir && pwd`/`basename "$jarfile"`
    ;;
  *)
    dir=`pwd`
    jarfile=`pwd`/`basename "$jarfile"`
    ;;
esac

# Perform a -C option if given right away.
cd "$cur_dir"

case $mode in
  unknown)
    usage
    ;;

  extract)
    make_tmp
    jar_list "$jarfile" > "$JARTMP"/list
    test "$#" = 0 && cp "$JARTMP"/list "$JARTMP"/chosen
    for arg
    do
      $skip && skip=false && continue
      case "$arg" in
	-C) skip=: ;;
	-C*) ;;
	*)
	  escaped=`echo "$arg" | sed -n 's/[][.^$\*]/\\&/' `
	  grep -e "^list/" >> "$JARTMP"/chosen
	  grep -e "^list$" >> "$JARTMP"/chosen
      esac
    done
    if $verbose; then
      sort < "$JARTMP"/chosen | uniq | xargs $UNZIP -o "$jarfile" | \
	sed -ne 's/^   creating/  created/p' -e 's/^  inflating/extracted/p'
    else
      sort < "$JARTMP"/chosen | uniq | xargs $UNZIP -o "$jarfile" > /dev/null
    fi
    ;;

  create)
    make_tmp
    $mkdir_p "$JARTMP"/out
    $mkdir_p "$JARTMP"/files
    tmp_jarfile="$JARTMP"/out/`basename "$jarfile"`
    make_files "$@"
    if test $manifest_kind != none; then
      make_manifest "$JARTMP"/files/META-INF/MANIFEST.MF $manifest_kind $manifest_file
    fi
    if $verbose; then
      (eval $out_redirect; cd "$JARTMP"/files && $ZIP -rv "$tmp_jarfile" $store .)
    else
      (cd "$JARTMP"/files && $ZIP -r "$tmp_jarfile" $store . > /dev/null)
    fi
    test "$jarfile" = "$tmp_jarfile" || mv "$tmp_jarfile" "$jarfile"
    ;;

  update)
    make_tmp
    $mkdir_p "$JARTMP"/files
    make_files "$@"
    case $manifest_kind in
      none)
	$verbose && (eval $out_redirect; echo removing manifest)
	$ZIP -d "$jarfile" META-INF/MANIFEST.MF > /dev/null
	;;
      *)
	make_manifest "$JARTMP"/files/META-INF/MANIFEST.MF $manifest_kind $manifest_file
	;;
    esac
    if $verbose; then
      (eval $out_redirect; cd "$JARTMP"/files && $ZIP -urv "$jarfile" $store .)
    else
      (cd "$JARTMP"/files && $ZIP -ur "$jarfile" $store . > /dev/null)
    fi
    ;;

  list)
    if $verbose; then
      jar_list_verbose "$jarfile"
    else
      jar_list "$jarfile"
    fi ;;

  index)
    ;;
esac

EXITCODE=$?
if test $EXITCODE = 0 && \
   test -n "$JARTMP" && test "$jarfile" = "$JARTMP"/out/tmp-stdin.jar; then
  case $mode in
    create|update) cat "$JARTMP"/out/tmp-stdin.jar ;;
  esac
fi
test -z "$JARTMP" || rm -rf "$JARTMP"
exit $EXITCODE

Re: Patch: Remove fastjar

[Bryce McKinlay]

Mark Wielaard wrote:
> On Thu, 2006-03-30 at 16:29 -0800, Per Bothner wrote:
>   
>> Ideally, I'd like to get rid of fastjar.  It should be replaced by a
>> wrapper on top of java.util.zip and java.util.jar.  I assume this is
>> what Sun does.  Is there any reason to not do that?
>>     
>
> Theoretically not. It would make bootstrapping things a bit more
> interesting. But as you said those things can be done with some careful
> thought about what gets build when/where and depends on what.

It shouldn't be a big problem. jar is only needed to create libgcj.jar 
and any other .jar files that are a part of the build. A "gjar" 
replacement written in java would be built to depend only on libgcj.so, 
so it will be built and working by the time we need to create the jars.

> But I am not really
> convinced that ripping out fastjar to force someone to write such a
> replacement to include in the gcc source tree is a very productive.
Well, of course it isn't.

Bryce

Re: Patch: Remove fastjar

[Per Bothner]

Bryce McKinlay wrote:
> Mark Wielaard wrote:
>> But I am not really
>> convinced that ripping out fastjar to force someone to write such a
>> replacement to include in the gcc source tree is a very productive.
> Well, of course it isn't.

One could argue it's a cleanup: We remove some code duplication.
Plus, at least historically, fastjar has been very incomplete,
with a fair bit of work needed to make it feature-complete.
Perhaps that has changed by now.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: Patch: Remove fastjar

[Tom Tromey]

>>>>> "Andrew" == Andrew Pinski <pinskia@physics.uc.edu> writes:

Andrew> Is there a reason why you are removing support from building
Andrew> fastjar inside the tree?

Not a particular reason -- it just seemed like the thing to do.

Maybe one of the build maintainers or SC could speak up and provide
direction here.

Andrew> It is a bit strange to remove a requirement to build
Andrew> part of GCC without documenting this new requirement.  

Yeah, I'll fix this.

Tom

Re: Patch: Remove fastjar

[Tom Tromey]

>>>>> "Mark" == Mark Wielaard <mark@klomp.org> writes:

Mark> Would it be possible to use the minizip
Mark> implementation from the included zlib to create the jar/zip
Mark> file?

Good idea.  I will look into this... I didn't realize that there was
a complete zip in here -- I thought there was only a mini-gzip.

Tom

Re: Patch: Remove fastjar

[Tom Tromey]

>>>>> "Per" == Per Bothner <per@bothner.com> writes:

Per> Ideally, I'd like to get rid of fastjar.  It should be replaced by a
Per> wrapper on top of java.util.zip and java.util.jar.  I assume this is
Per> what Sun does.  Is there any reason to not do that?

I agree, this is the best way for us to continue delivering a complete
system.  Ideally "someone" will write a jar for the Classpath tools
directory, and then we'll just build it as part of libjava.

I would prefer that this not be a requirement for getting the fastjar
patch checked in, basically since I'm not in the mood to actually
write the thing :-)

Tom

Re: Patch: Remove fastjar

[DJ Delorie]

> Andrew> Is there a reason why you are removing support from building
> Andrew> fastjar inside the tree?
> 
> Maybe one of the build maintainers or SC could speak up and provide
> direction here.

My personal opinion is, if leaving it in doesn't bother anything,
leave it in.  Especially if there's even a slight chance that someone
would benefit from such support.

Removing it would make sense if there were a reason to remove it, like
a hairy configure test or complex makefile rules.  It's it's just Yet
Another Module, I see no reason to remove support for it.

Re: Patch: Remove fastjar

[Bryce McKinlay]

Per Bothner wrote:
> Bryce McKinlay wrote:
>> Mark Wielaard wrote:
>>> But I am not really
>>> convinced that ripping out fastjar to force someone to write such a
>>> replacement to include in the gcc source tree is a very productive.
>> Well, of course it isn't.
>
> One could argue it's a cleanup: We remove some code duplication.

Yeah, I agree with that - a Java implementation of jar would be better. 
But, surely the removal of fastjar should follow once a replacement is 
ready.

Bryce

Re: Patch: Remove fastjar

[Per Bothner]

Bryce McKinlay wrote:
> Per Bothner wrote:
>> One could argue it's a cleanup: We remove some code duplication.
> 
> Yeah, I agree with that - a Java implementation of jar would be better. 
> But, surely the removal of fastjar should follow once a replacement is 
> ready.

Stallman might reasonably argue that removing fastjar provides motivation
to do the job.  And we're not really "removing" fastjar; we're making
it an external dependency - the way (say) ar is.  Logically jar doesn't
belong in gcc any more than ar does - at least not as long as fastjar
doesn't make use of gcc headers or libraries.  A rewritten jar that is
just a thin wrapper over java.util.jar *might* be a different matter.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: Patch: Remove fastjar

[Mark Mitchell]

Tom Tromey wrote:

> fastjar doesn't have a home yet.  It was rejected from savannah
> because fastjar.texi is GPL and not GFDL.  

Thanks for trying.  I didn't realize savannah had that requirement.

> I didn't include the generated diffs or the diff which actually
> removes the fastjar directory.
> 
> Built on x86 FC4.  Ok for trunk?

Yes.

I've read through the remainder of the thread, and see that various
people have various suggestions/criticisms.  However, removing fastjar
isn't up for debate; the decision has been made, and we have to live
with it.

It is fine, however, if you want to leave in the support for building
with fastjar in-tree; there's no FSF problem with having that support in
place.  Everyone agrees that fastjar is free software, so it's just the
actual inclusion in GCC that's an issue.

Thank you for following through on this chore; I recognize it doesn't
feel as satisfying, as, say, fixing a bug. :-)

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: Patch: Remove fastjar

[Laurent GUERBY]

On Thu, 2006-03-30 at 15:53 -0700, Tom Tromey wrote:
> fastjar doesn't have a home yet.  It was rejected from savannah
> because fastjar.texi is GPL and not GFDL.  Most likely I will import
> fastjar into the rhug repository on sourceware.org (and then fix it up
> to actually build). 

You might want to try gna.org, the FSF France sponsored repository,
they are a bit more flexible on this kind of "thing".

http://www.gna.org/

Laurent

Re: Patch: Remove fastjar

[Tom Tromey]

>>>>> "DJ" == DJ Delorie <dj@redhat.com> writes:

DJ> My personal opinion is, if leaving it in doesn't bother anything,
DJ> leave it in.  Especially if there's even a slight chance that someone
DJ> would benefit from such support.

Ok.  I reverted that part of the patch and did another build, and it
worked fine.  So I will be checking that in.

Tom

Re: Patch: Remove fastjar

[Tom Tromey]

>>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:

Mark> Would it be possible to use the minizip
Mark> implementation from the included zlib to create the jar/zip
Mark> file?

Tom> Good idea.  I will look into this... I didn't realize that there was
Tom> a complete zip in here -- I thought there was only a mini-gzip.

I looked into this a bit.  It turns out to be a pain.  If someone else
wants to make a stab at it, that is fine by me; but I'm dropping this
idea.

Tom

Re: Patch: Remove fastjar

[Tom Tromey]

>>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:

Tom> fastjar doesn't have a home yet.  It was rejected from savannah
Tom> because fastjar.texi is GPL and not GFDL.

Matthias Klose (who initially wrote fastjar.texi) suggested a
compromise solution, which was that the file be changed to the GFDL
but that there be no cover or invariant sections.  This was approved
by the FSF, so there is now a fastjar project on savannah.  I will
import the sources there in the near future, after making the other
required changes for hosting.

Tom

Re: Patch: Remove fastjar

[Richard Guenther]

On 4/1/06, Mark Mitchell <mark@codesourcery.com> wrote:
> Tom Tromey wrote:
>
> > fastjar doesn't have a home yet.  It was rejected from savannah
> > because fastjar.texi is GPL and not GFDL.
>
> Thanks for trying.  I didn't realize savannah had that requirement.
>
> > I didn't include the generated diffs or the diff which actually
> > removes the fastjar directory.
> >
> > Built on x86 FC4.  Ok for trunk?
>
> Yes.
>
> I've read through the remainder of the thread, and see that various
> people have various suggestions/criticisms.  However, removing fastjar
> isn't up for debate; the decision has been made, and we have to live
> with it.

Now, the fastjar removal is a desaster.  Getting the "package" from savannah
(there's only a CVS checkout possible at the moment) gives you an unbuildable
source tree which has gcc dependencies all over the place and so usual
10 minutes
fiddling with the makefiles didn't result in a buildable fastjar
package.  This suggests
that fastjar is really not a separate package from gcc.  (It requires
libiberty, its
documentation requires all sorts of gcc texi magic which I couldn't get right

This sucks.

Richard.

Re: Patch: Remove fastjar

[Andrew Haley]

Richard Guenther writes:
 > On 4/1/06, Mark Mitchell <mark@codesourcery.com> wrote:
 > > Tom Tromey wrote:
 > >
 > > > fastjar doesn't have a home yet.  It was rejected from savannah
 > > > because fastjar.texi is GPL and not GFDL.
 > >
 > > Thanks for trying.  I didn't realize savannah had that requirement.
 > >
 > > > I didn't include the generated diffs or the diff which actually
 > > > removes the fastjar directory.
 > > >
 > > > Built on x86 FC4.  Ok for trunk?
 > >
 > > Yes.
 > >
 > > I've read through the remainder of the thread, and see that various
 > > people have various suggestions/criticisms.  However, removing fastjar
 > > isn't up for debate; the decision has been made, and we have to live
 > > with it.
 > 
 > Now, the fastjar removal is a desaster.  Getting the "package" from
 > savannah (there's only a CVS checkout possible at the moment) gives
 > you an unbuildable source tree which has gcc dependencies all over
 > the place and so usual 10 minutes fiddling with the makefiles
 > didn't result in a buildable fastjar package.  This suggests that
 > fastjar is really not a separate package from gcc.  (It requires
 > libiberty, its documentation requires all sorts of gcc texi magic
 > which I couldn't get right

It ought to be possible to build libgcj.jar with Info-ZIP, but I'm not
sure that having an external dependency on that is any better than
having a dependency on fastjar.

Andrew.

Re: Patch: Remove fastjar

[Tom Tromey]

>>>>> "Richard" == Richard Guenther <richard.guenther@gmail.com> writes:

Richard> Now, the fastjar removal is a desaster.

Yup.

Richard> This suggests that fastjar is really not a separate package
Richard> from gcc.  (It requires libiberty, its documentation requires
Richard> all sorts of gcc texi magic which I couldn't get right

Yes, nobody has had the motivation to fix fastjar's configury.  It
probably isn't hard to do.  If you're interested, tell me your
savannah user id and I will give you write access.

Tom