bugmake - Bugs: bug #45728, .VARIABLES not updated after...


bug #45728: .VARIABLES not updated after undefine

Submitter:  Andreas Schwab <schwab>
Submitted:  Mon 10 Aug 2015 01:23:58 PM UTC
Severity:  3 - Normal Item Group:  Bug
Status:  Fixed Privacy:  Public
Assigned to:  psmith Open/Closed:  Closed
Component Version:  4.0 Operating System:  Any
Fixed Release:  4.2 Triage Status:  Small Effort
* Mandatory Fields

Add a New Comment Rich Markup

Mon 14 Mar 2016 12:47:10 PM UTC, comment #4: 

Typo.  I fixed it last night in my local repo but haven't pushed that yet.  It shouldn't matter.

Paul D. Smith <psmith>
Group administrator
Mon 14 Mar 2016 09:12:19 AM UTC, comment #3: 

Why do the two variables have different types?

+static unsigned int variable_changenum;
+  static unsigned long last_changenum = 0;

Andreas Schwab <schwab>
Sun 13 Mar 2016 10:29:16 PM UTC, comment #2: 

This was tricky.  GNU make tries to avoid the overhead of computing .VARIABLES unless you need it, and also unless it changed from the last time it was computed.  It used the number of variables in the hash table to determine whether the value needed to be recomputed.  This was find when we weren't removing entries on undefine, but when we started to do that now the value is not reliable: if you remove one variable and add one variable (or any equal number of adds and removes) in between expanding .VARIABLES then it doesn't detect that there was a change and doesn't re-compute the .VARIABLES value.

I fixed this in Git by introducing a "change number" for variables which is monotonically increasing, during both adds and removes.

Paul D. Smith <psmith>
Group administrator
Mon 28 Sep 2015 04:34:16 PM UTC, comment #1: 

I think the problem is a bit larger than what is exhibited here.

I started with the following script:

# \
gmake --version; \
exec gmake --warn-undefined-variables -f "$0" "$@"

undefine MY_foo
$(warning MY variables: $(filter MY_%,${.VARIABLES}))
$(foreach x,$(filter MY_%,${.VARIABLES}),$(eval undefine ${x}))
$(warning MY Variables: $(filter MY_%,${.VARIABLES}))

all: ; @true

If I run that script, I get output on par with the originally submitted bug -- though it should be noted that it at least appears to work fine unless you use $(foreach).

If I add an evaluation of .VARIABLES between lines 6 & 7 (copy/paste one of the $(warning) lines) I get different (also buggy) behavior.  If I put the $(warning) line in a variable and evaluate that, I get other buggy behavior.

Mon 10 Aug 2015 01:23:58 PM UTC, original submission:  

This makefile demonstrates a bug in the expansion of .VARIABLES:

$ cat Makefile.variables
MY_one := 1
MY_two := 2
$(foreach v, $(filter MY_%, $(.VARIABLES)), $(eval undefine $v))
MY_foo := foo
MY_bar := bar
all:; @echo MY Variables = $(filter MY_%, $(.VARIABLES))
$ make -f Makefile.variables
MY Variables = MY_one MY_two

Andreas Schwab <schwab>


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

Attach Files:

Attached Files


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by psmith (Posted a comment)
  • -email is unavailable- added by schwab (Submitted the item)

    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 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-03-13 psmith StatusNone Fixed
        Assigned toNone psmith
        Open/ClosedOpen Closed
        Fixed ReleaseNone 4.2
        Triage StatusNone Small Effort
    2015-09-03 schwab Attached File- Added 0001-SV-45728-Force-recomputing-.VARIABLES-when-a-variabl.patch, #34803

    Back to the top

    Powered by Savane 3.12.
    Corresponding source code