Fri 29 Oct 2010 12:32:11 PM UTC, comment #9:
There are two -a0 in there that should be -a1, sorry ...
|
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.
|
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. :-)
|
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.
|
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:
|
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.
|
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.
|
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
|
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.
|
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
.)
|