[bug #26207] corner cases in 'override' logic for variables

[Manoj Srivastava]

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 address@hidden

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/