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

 
 

bug #30606: mysterious behavior from $(if)

Submitted by:  Reinier Post <r_p>
Submitted on:  Fri 30 Jul 2010 07:07:46 PM UTC  
 
Severity: 3 - NormalItem Group: Bug
Status: Not A BugPrivacy: Public
Assigned to: NoneOpen/Closed: Closed
Component Version: 3.81Operating System: None
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.

 

(Jump to the original submission 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):

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:

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:

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

Paul D. Smith <psmith>
Project 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:

Paul D. Smith <psmith>
Project 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>
Project 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

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):

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 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 tnmurphy (Posted a comment)
  • -unavailable- added by r_p (Submitted the item)
  •  

    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
    Fri 30 Jul 2010 07:37:32 PM UTCpsmithStatusNone=>Not A Bug
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1