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 524378@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