bugmake - Bugs: bug #26207, corner cases in 'override' logic...


bug #26207: corner cases in 'override' logic for variables

Submitter:  Manoj Srivastava <srivasta>
Submitted:  Thu 16 Apr 2009 06:55:02 PM UTC
Severity:  3 - Normal Item Group:  Bug
Status:  Fixed Privacy:  Public
Assigned to:  psmith Open/Closed:  Closed
Component Version:  3.81 Operating System:  POSIX-Based
Fixed Release:  3.82 Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup

Sun 31 May 2009 10:06:02 PM UTC, comment #1: 

The initial behavior is indeed correct, as Manoj has explained.  Once a variable is elevated to the status of "override", which is the highest priority a variable can have, any subsequent assignment or append to that variable which is of a lower priority will be ignored.  You can continue to append to that variable, or even change its value, but only if you precede the subsequent assignments with "override" as well.  I added some text to the GNU make manual that might make this clearer.

As for the other effects you observed, those are due to a real bug in the system.  I've attached a patch here which I will be committing as soon as Savannah's source control systems come back up.

(file #18213)

Paul D. Smith <psmith>
Group administrator
Thu 16 Apr 2009 06:55:02 PM UTC, original submission:  


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

Manoj Srivastava <srivasta>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #18213:  read.diff added by psmith (555B - text/x-patch - Patch to fix override in target-specific variables)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by psmith (Updated the item)
  • -email is unavailable- added by srivasta (Submitted the item)
  • -email is unavailable- added by srivasta
  • -email is unavailable- added by srivasta
  • -email is unavailable- added by srivasta

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-07-28 psmith Fixed Release4.0 3.82
    2009-05-31 psmith Attached File- Added read.diff, #18213
        StatusNone Fixed
        Assigned toNone psmith
        Open/ClosedOpen Closed
        Fixed ReleaseNone 4.0
    2009-04-16 srivasta Carbon-Copy- Added -email is unavailable-
        Carbon-Copy- Added -email is unavailable-
        Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code