[Top][All Lists]
[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-----
- 'set -u' and $SHELL in makefiles [was: GNU M4],
Eric Blake <=