bugmake - Bugs: bug #30606, mysterious behavior from $(if)

 
 

bug #30606: mysterious behavior from $(if)

Submitter:  Reinier Post <r_p>
Submitted:  Fri 30 Jul 2010 07:07:46 PM UTC
   
 
Severity:  3 - Normal Item Group:  Bug
Status:  Not A Bug Privacy:  Public
Assigned to:  None Open/Closed:  Closed
Component Version:  3.81 Operating System:  None
Fixed Release:  None Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 29 Oct 2010 12:32:11 PM UTC, comment #9: 

There are two -a0 in there that should be -a1, sorry ...

Reinier Post <r_p>
Fri 29 Oct 2010 12:24:54 PM UTC, comment #8: 

I still haven't figured out how to fix my Makefile, so I'll take Paul up on his offer.

I have a command to generate Graphviz input files from CSV files.
My initial rule looked like this (but with a TAB, of course):


%.dot: %.csv
  deps.pl $? > $@


But the command has several options that I often use, in various combinations.  The number of option values for each is finite, so I can just enumerate all possible combinations:


%.dot: %.csv
  deps.pl $? > $@
%-b.dot: %.csv
  deps.pl -b $? > $@
%-a0.dot: %.csv
 deps.pl -a0 $? > $@
%-a0-b.dot: %.csv
 deps.pl -b -a0 $? > $@
%-a1.dot: %.csv
 deps.pl -a0 $? > $@
%-a1-b.dot: %.csv
 deps.pl -b -a0 $? > $@
%-d.dot: %.csv
  deps.pl -t. $? >$@
%-d-b.dot: %.csv
  deps.pl -t. -b $? > $@
(...)

I'm trying to summarize these rules into a single one with a couple of nested foreach loops (or anything else) to loop over the possible option values (including nothing at all).  Note that suffix and option aren't always identical.


Reinier Post <r_p>
Fri 30 Jul 2010 09:12:28 PM UTC, comment #7: 

This problem has tripped me up 100 times if not more and I almost think I have suffered brain damage from trying to get my head around it in a few cases.

I need eval though.

What I want to say is that nobody should ever feel bad if they have trouble with this because it's very tricky. :-)

Timothy N Murphy <tnmurphy>
Fri 30 Jul 2010 08:48:22 PM UTC, comment #6: 

Ugh, my comment got truncated.  I used this example:


define T
b := $(subst aa,,$(1))
yn := $(if $(strip $(b)),y,n)
vs := $(vs) $(1):$(yn)
endef
$(info $(value T))


will show the string that make is storing as the value of T, without any expansion before it's printed.

Paul D. Smith <psmith>
Group administrator
Fri 30 Jul 2010 08:46:49 PM UTC, comment #5: 

If by "already expanded ... when the template is being defined" you mean after the define T ... endef, then you're not correct.  define, by itself, uses deferred expansion (just like "T = $(foo)") and so right after the define the value of T has NOT been expanded.

You can see this yourself using the $(info ...) function; very handy for debugging expansion issues:


define T
b := $(subst aa,,$(1))
yn := $(if $(strip $(b)),y,n)
vs := $(vs) $(1):$(yn)
endef
$(info $(value T))

will show you the value of the T variable without expanding it first... this is the text string that make is keeping for the variable T.

Paul D. Smith <psmith>
Group administrator
Fri 30 Jul 2010 07:55:15 PM UTC, comment #4: 

Never mind.

The problem is that the variables are already expanded, and the functions called, when the template is being defined, when I expect them to be expanded only when it is called.

Resolved by doubling all $s except those on the arguments.

Sorry.

Reinier Post <r_p>
Fri 30 Jul 2010 07:37:32 PM UTC, comment #3: 

Tim is correct; as far as I can tell this is expected behavior.  If you tell us what you're actually trying to do (for example, what is the output you WANTED to see from this) we can give you more details.

As a tool, $(eval ...) is a chainsaw.  It's easy to cut off a limb if you're not very, very careful with it.  It's likely (but not certain of course) that you can do the same job with tools that are a little less dangerous... if you describe what the job is that you're trying to accomplish.

Paul D. Smith <psmith>
Group administrator
Fri 30 Jul 2010 07:22:54 PM UTC, comment #2: 

Hi,

The $(call) expands everything, so you get this:

lets say $1=ab

b := ab
yn := n
vs := ab:


You might ask why :-)

Well when the $(if) is expanded by call, b has no value - the assignment has not been executed yet because your exec happens after your call.

You need to protect things such that the call can't expand them prematurely.

e.g. $1 doesn't really need protection but you do need $$(if and $$(strip $$(b)) and $$(yn)


Cheers,

Tim

Timothy N Murphy <tnmurphy>
Fri 30 Jul 2010 07:15:40 PM UTC, comment #1: 

The problem is not with $(if) as I thought:
replacing it with


ifeq ($(b),ab)
yn := y
else
yn := n
endif


produces the same output.

Reinier Post <r_p>
Fri 30 Jul 2010 07:07:46 PM UTC, original submission:  

With the following Makefile (simplified from my actual Makefile):


define T
b := $(subst aa,,$(1))
yn := $(if $(strip $(b)),y,n)
vs := $(vs) $(1):$(yn)
endef

tests := ab ab ab ab ab ab ab

$(foreach t,$(tests), \
  $(eval $(call T,$(t))) \
)

all:; @echo $(vs)


I get the following output:

+verbatim
ab: ab:n ab:y ab:y ab:y ab:y ab:y
-verbatim-

What on earth is going on here?  How can I fix it?
(I put the $(strip) in to be sure it wasn't related to
https://savannah.gnu.org/bugs/?5798
.)

Reinier Post <r_p>

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

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 tnmurphy (Posted a comment)
  • -email is unavailable- added by r_p (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 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-07-30 psmith StatusNone Not A Bug
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code