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

 
 

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

Submitted by:  Manoj Srivastava <srivasta>
Submitted on:  Thu 16 Apr 2009 06:55:02 PM UTC  
 
Severity: 3 - NormalItem Group: Bug
Status: FixedPrivacy: Public
Assigned to: Paul D. Smith <psmith>Open/Closed: Closed
Component Version: 3.81Operating System: POSIX-Based
Fixed Release: 3.82Triage Status: None

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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>
Project AdministratorIn charge of this item.
Thu 16 Apr 2009 06:55:02 PM UTC, original submission:

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

Manoj Srivastava <srivasta>

 

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

Attach File(s):
   
   
Comment:
   

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
  • -unavailable- added by psmith (Updated the item)
  • -unavailable- added by srivasta (Submitted the item)
  • -unavailable- added by srivasta
  • -unavailable- added by srivasta
  • -unavailable- added by srivasta
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 9 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 28 Jul 2010 06:15:40 AM UTCpsmithFixed Release4.0=>3.82
    Sun 31 May 2009 10:06:02 PM UTCpsmithAttached File-=>Added read.diff, #18213
      StatusNone=>Fixed
      Assigned toNone=>psmith
      Open/ClosedOpen=>Closed
      Fixed ReleaseNone=>4.0
    Thu 16 Apr 2009 06:55:02 PM UTCsrivastaCarbon-Copy-=>Added -unavailable-
      Carbon-Copy-=>Added -unavailable-
      Carbon-Copy-=>Added -unavailable-

    Back to the top


    Powered by Savane 3.1-cleanup1