Re: [lzip-bug] Lzip configure and Makefile patch

[Antonio Diaz Diaz]

Hi Jeffrey,

Thank you for the patch.

Jeffrey Walton wrote:
> The patch includes additional two small changes. First,
> SHELL=/bin/sh was moved to the first line per GNU Coding Standards.

Where in the Standards did you find that 'SHELL=/bin/sh' must be the first 
line in Makefile.in? All I could find is this:

[1] http://www.gnu.org/prep/standards/html_node/Makefile-Basics.html
  Every Makefile should contain this line:
  SHELL = /bin/sh

I guess that defining it before using it is enough. Moreover, moving 
'SHELL=/bin/sh' to the first line in Makefile.in does not place it at the 
first line of the Makefile.

> Second, variables like "${option}" was quoted due to Shellcheck findings.

Applied, thanks. This one is interesting. It seems to work as is (without 
the patch), and the configure script of GNU make 4.3 uses it unquoted in 
some places as lzip does. But better safe than sorry.

> Using variables in the environment may not seem like a big change, but
> it makes a difference when build 60 or 80 packages. When I need to
> build a bunch of packages, it is very helpful when variables are set
> once in the environment and everything "just works" like Autotools.

You are right that using environment variables is not a big change. In fact 
zutils once used environment variables (see zutils 0.8). But I decided to 
not use them for several reasons. For example:

http://www.gnu.org/software/make/manual/html_node/Environment.html
It is not wise for makefiles to depend for their functioning on environment 
variables set up outside their control, since this would cause different 
users to get different results from the same makefile. This is against the 
whole purpose of most makefiles.

Setting environment variables for configure is deprecated because running 
configure in varying environments can be dangerous. The configure script of 
lzip implements the method recommended by autoconf to pass variables:

http://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Defining-Variables.html
Variables not defined in a site shell script can be set in the environment 
passed to configure. However, some packages may run configure again during 
the build, and the customized values of these variables may be lost. In 
order to avoid this problem, you should set them in the configure command 
line, using 'VAR=value'. For example:
     ./configure CC=/usr/local2/bin/gcc

http://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Setting-Output-Variables.html
If for instance the user runs 'CC=bizarre-cc ./configure', then the cache, 
config.h, and many other output files depend upon bizarre-cc being the C 
compiler. If for some reason the user runs ./configure again, or if it is 
run via './config.status --recheck', (See Automatic Remaking, and see 
config.status Invocation), then the configuration can be inconsistent, 
composed of results depending upon two different compilers.
[...]
Indeed, while configure can notice the definition of CC in './configure 
CC=bizarre-cc', it is impossible to notice it in 'CC=bizarre-cc 
./configure', which, unfortunately, is what most users do.
[...]
configure: error: changes in the environment can compromise the build

Note that the build scripts of some distros pass variables to configure like 
this:
  ./configure --prefix=/usr CXXFLAGS="$CXXFLAGS"

> Thanks again for an easy to use package.

You are welcome. :-)

Antonio.