[Top][All Lists]

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

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

From: Antonio Diaz Diaz
Subject: Re: [lzip-bug] Lzip configure and Makefile patch
Date: Wed, 01 Apr 2020 02:42:19 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv: Gecko/20110420 SeaMonkey/2.0.14

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:

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:

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

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. :-)


reply via email to

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