URL:
<http://savannah.gnu.org/bugs/?26207>
Summary: corner cases in 'override' logic for variables
Project: make
Submitted by: srivasta
Submitted on: Thu 16 Apr 2009 01:55:02 PM CDT
Severity: 3 - Normal
Item Group: Bug
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Component Version: 3.81
Operating System: POSIX-Based
Fixed Release: None
_______________________________________________________
Details:
Hi,
This bug was submitted to Debian, and lives at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=524378
Please CC any replies to 524...@bugs.debian.org.
I ran into some odd behaviour yesterday thanks to a bug in one of my
makefiles, but this seems to have raised some questions about how make
actually should behave in that case. The initial problem was that a rule was
(inadvertantly) being composed something like this:
target: override FOO += bar
target: FOO += baz
Manoj and I discussed this on IRC, and he expressed the opinion that it was
intuitive and correct for all normal assignments after an override to be
ignored (as if that variable really was assigned on the command line, even if
it isn't). This isn't documented as such, but I don't really disagree with
that as being a fairly reasonable interpretation -- and indeed in my case, the
missing override on the second line _was_ an accident and a bug in that
makefile.
I do however have a couple of examples to share that don't behave
according to that interpretation, and which may be of interest (:
In this case, the target specific override appears to be ignored
completely if the variable is passed on the command line ...
override FOO += 1
FOO += 2
a: override BAR += 11
a: BAR += 12
a:
echo "got FOO = $(FOO), BAR = $(BAR)"
$ make -f a.mk
got FOO = 1, BAR = 11
$ make -f a.mk FOO=3 BAR=13
got FOO = 3 1, BAR = 13
This one is even more interesting, the second normal assignment of BAR
succeeds after the override, though the first does not:
override FOO += 1
FOO += 2
a: override BAR += 11
a: BAR += 12
a: BAR += zomg!
a:
@echo "got FOO = $(FOO), BAR = $(BAR)"
$ make -f a.mk
got FOO = 1, BAR = 11 zomg!
$ make -f a.mk FOO=3 BAR=13
got FOO = 3 1, BAR = 13
I don't really have a strong opinion as to how this should be resolved,
empirically the only reasonable assumption I can make at present is that
mixing overrides with normal assignments results in undefined behaviour, and
it wouldn't seem unreasonable to me to formally declare that as such.
OTOH maybe this reveals a glitch in the internal logic somewhere that should
be looked into.
-- System Information:
Debian Release: 5.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?26207>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
