re: CVS commit: src/distrib/news68k/floppies/ramdisk

[matthew green <mrg%eterna.com.au@localhost>]

   On Sat, Mar 27, 2004 at 08:19:26PM +0900, Izumi Tsutsui wrote:
   > In article <20198.1080375229%splode.eterna.com.au@localhost>
   > mrg%eterna.com.au@localhost wrote:
   > 
   > > x_gzip is basically an old version of usr.bin/gzip.  ideally the latter
   > > can be updated to remove more features with -DSMALL and x_gzip has no
   > > sources in it... things i can see off hand:
   > 
   > I tried a quick patch which disables bzip2 and compress support by
   > -DNO_BZIP2_SUPPORT and -DNO_COMPRESS_SUPPORT:
   > ---
   > % ls -lS gzip*
   > -rwxr-xr-x  1 100  100  218791 Mar 27 19:55 gzip-static
   > -rwxr-xr-x  1 100  100  214652 Mar 27 19:55 gzip-static_without_compress
   > -rwxr-xr-x  1 100  100  168745 Mar 27 19:55 gzip-static_without_bzip2
   > -rwxr-xr-x  1 100  100  164478 Mar 27 19:56 
gzip-static_without_bzip2_compress
   > ---
   > Current distrib/utils/x_gzip is:
   > ---
   > -rwxr-xr-x  1 100  100  145758 Mar 27 20:08 x_gzip-static
   > ---
   > Is this difference worth? Now distrib/utils/x_gzip should only have
   > Makefile with some CPPFLAGS which disables unneeded features?
   
   Unless it's the same size we need to leave x_gzip. On areas cramped for space
   this just barely fits.

is it -DSMALL as well?  that does stuff already...  the changes i had
meantioned i don't mean are going to be done intime for 2.0 branch, but
some of these would probably bring it down to x_gzip size (with -DSMALL)

the only real issue is if x_gzip isn't good enough for "gzip -l" that
sysinst now supports, there is something else needed..


also, comparing static bins isn't quite right, the only real way to
compare their relative additions (due to libs) to crunchbin files is
to crunchthem and see :)


tsutsui, please commit your changes so i can work on gzip afterwords.


.mrg.