bug-automake
[Top][All Lists]
Advanced

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

'set -u' and $SHELL in makefiles [was: GNU M4]


From: Eric Blake
Subject: 'set -u' and $SHELL in makefiles [was: GNU M4]
Date: Wed, 30 Jan 2008 13:06:45 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[adding bug-automake; this is
http://thread.gmane.org/gmane.comp.gnu.m4.bugs/2388]

According to Chan, Lawson on 1/30/2008 12:46 PM:
|  Hi Eric,
|
| Thanks for your reply.  I am sorry that I have difficulties in removing
the disclaimer because it is out of my control.

Nothing prevents you from using a free webmail account, or finding a
newsreader gateway that won't add a disclaimer (I personally like gmane).

|  I am running the make in both shell (bash or Korn) and they have
exactly the same behaviour.

It doesn't matter what shell you ran make from; what mattered is what
shell make was running as it spawned commands.  What does 'env | grep
SHELL' say?  Your log shows that you are running bash 2.03, which is
rather old, but I don't think that's an issue.  I personally know that M4
builds just fine on Solaris 8, so it is something about your environment
that caused your failure, and not a flaw in the M4 package.

|
| /M4/m4-1.4.10/checks
|  bash: fail: unbound variable
|  *** Error code 1
|  make:  Fatal error: Command failed for target 'all-recursive'
|
| Here is the attached configure and make output file for your reference.

You still didn't show me the command lines that you typed.

|
| Yes, the ./configure is successfully executed.  Any thought about this?

It looks like an automake issue to me.  It looks like you have somehow
enabled the 'set -u' option of bash.

Looking at what automake outputs for $(RECURSIVE_TARGETS) in each
Makefile, I see:

$(RECURSIVE_TARGETS):
~        @failcom='exit 1'; \
~        for f in x $$MAKEFLAGS; do \
~          case $$f in \
~            *=* | --[!k]*);; \
~            *k*) failcom='fail=yes';; \
...
~          || eval $$failcom; \
~        done; \
~        if test "$$dot_seen" = "no"; then \
~          $(MAKE) $(AM_MAKEFLAGS) "$$target-am" || exit 1; \
~        fi; test -z "$$fail"

In other words, if you did NOT use 'make -k', then eval $$failcom never
initialized $fail, and test -z "$$fail" ends up expanding an undefined
$fail, explaining the bash warning.  I've never seen a make implementation
use 'set -u' (although I do know that some make use an implicit 'set -e'),
and since POSIX requires make to ignore $SHELL from the environment, I'm
not quite sure whether the user had a posix-compliant setup to begin with.
~ Then again, POSIX states that it is not portable to assign SHELL within a
makefile, while autoconf recommends doing exactly that via address@hidden@,
and 'set -u' _is_ posix-compliant.  So should automake cater to this weird
SHELL setting by doing failcom='fail=; exit 1' as the default value for
$failcom (and audit for any other potentially unset variables)?  Or is it
better to figure out how this user got 'set -u' enabled in your SHELL in
the first place, and add workarounds (perhaps in autoconf, rather than
automake?) to avoid such an awkward setup?

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHoNjV84KuGfSFAYARAj2lAJoCjxFaHdSDoREq7AHBJg+EGzniCQCeK4TL
VcOy9V5e618/oxh/ZycO59Q=
=neTy
-----END PGP SIGNATURE-----




reply via email to

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