bugmake - Bugs: bug #29757, Target-specific variables change...

 
 

bug #29757: Target-specific variables change their flavor

Submitted by:  None
Submitted on:  Mon 03 May 2010 06:42:21 PM UTC  
 
Severity: 3 - NormalItem Group: Bug
Status: Not A BugPrivacy: Public
Assigned to: NoneOpen/Closed: Closed
Component Version: 3.81Operating System: POSIX-Based
Fixed Release: NoneTriage Status: None

Add a New Comment(Rich Markup)
   

You are not logged in

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

 

Thu 01 Jul 2010 06:11:04 AM UTC, comment #3:

Although you may find it undesirable, make is behaving correctly here. A variable assignment that appears in a target-specific context is not evaluated AT ALL until the target is about to be invoked. By the time the target is invoked, the value of "deferred_var" is now "nothing" and so make's behavior is correct.

The way in which target-specific variables work means that there is no possible way in which they can be expanded when they are defined in the makefile. Remember that target-specific variables are inherited via the prerequisite relationship, so the initial value of static_var to append to CANNOT BE KNOWN until the target is to be built, because only then do we know what its parent target context is.

Paul D. Smith <psmith>
Project Administrator
Sat 26 Jun 2010 06:44:47 AM UTC, comment #2:

Sorry. You were right. But this is not convenient to have just one way to append to a variable. Note that at least 2 *makes have :+= operator: dmake and fastmake. I guess GNU make could think about it.

Vitaly Grechko <fastmake>
Fri 25 Jun 2010 09:03:10 PM UTC, comment #1:

I think you are wrong. Simple or deferred expansion is connected to operator, not variable. Variable does not know what way it was assigned. To get what you want you can use :+= implemented in 'Fastmake' tool. Unfortunately this operator is not implemented in GNU make yet.

Vitaly Grechko <fastmake>
Mon 03 May 2010 06:42:21 PM UTC, original submission:

I encountered this problem when writing a complex Makefile, so at the beginning I didn't figured out where the problem was. But then I managed to isolate it, and I was astonished. Here a simple Makefile:

deferred_var = $(wildcard *)
static_var := some text

foo: static_var += $(deferred_var)

deferred_var = nothing

foo:
@echo "$(static_var)"

If I place it in an empty directory, I would expect the output of make to be:
some text Makefile
But, instead of that, I get:
some text nothing

I think this is wrong, static_var is a simply-expanded variable, and:
"When you add to a variable's value with `+=', make acts essentially as if you had included the extra text in the initial definition of the variable. If you defined it first with `:=', making it a simply-expanded variable, `+=' adds to that simply-expanded definition, and expands the new text before appending it to the old value just as `:=' does"

If I replace
foo: static_var += $(deferred_var)
with
foo: static_var := $(static_var) $(deferred_var)
it works as expected, but it's an ugly workaround.

This happens of course only when doing a target-specific assignment, but it's quite annoying.

Anonymous

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by psmith (Posted a comment)
  • -unavailable- added by fastmake (Posted a comment)
  •  

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

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 01 Jul 2010 06:11:04 AM UTCpsmithStatusNone=>Not A Bug
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1