[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: dist-xz compression level

From: Ralf Wildenhues
Subject: Re: dist-xz compression level
Date: Mon, 12 Apr 2010 20:31:22 +0200
User-agent: Mutt/1.5.20 (2009-10-28)


* Jim Meyering wrote on Mon, Apr 12, 2010 at 11:44:01AM CEST:
> Pavel Sanda wrote:
> >> For my use, xz -9 is far too slow for anything except the
> >> final "make dist" I run just prior to a release.
> >>
> >> For a release, I run this, via one of the
> >> alpha, beta or stable targets in gnulib's
> >>
> >>   $(MAKE) dist XZ_OPT=-9ev
> >
> > Is it possible to setup this to be the default inside makefiles?
> > (I use make dist only for the final release...)
> Sure.
> Create a GNUmakefile containing
>   export XZ_OPT=-9ev
> and just passing all other rules to the default Makefile.

This is fine for projects where the developers use GNU make anyway.
Automake strives for more portable solutions where possible.

I looked at a couple of manpages now.  gzip, xz, bzip2, and zip allow
optional arguments through environment variables GZIP, XZ_OPT, BZIP2,
and ZIPOPT, respectively.  compress can safely be ignored, and lzip
improved I guess.  AFAICS all give the environment variables lower
priority than command-line arguments.  Automake rules currently use GZIP
by setting

before calling gzip, but the other compression rules do not do anything
similar.  We could thus do the same for the other compressors.  This
would break backward compatibility and require adjusting
An alternative would be something like
  if test -n "$(GZIP_ENV)"; then GZIP="$(GZIP_ENV)"; export GZIP; fi; \

which would be more backward-compatible.

Next question is which variable names we should use.  XZ_ENV BZIP2_ENV
ZIP_ENV would be consistent.

My idea would be to implement this for master, and revert the recent
xz -9 patch on branch-1.11.  Comments, criticism?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]