Re: EXT :Re: Problem with makefile

[Paul Smith]

On Wed, 2013-03-06 at 19:52 +0000, Hiebert, Darren (IS) wrote:
> Then why did the expansion triggered by line 13 still show up the same
> as the others when running "make expansion"? After all, the assignment
> at line 10 should have happened the first time, so its reference at
> line 13 should have been acceptable and been expanded properly the
> first time, shouldn't it?

Because in the "expansion" makefile .tmp.mak you do this:

    $(eval $(call ...))

Then LATER you do this:

    $(info $(call ...))

So you FIRST run the $(eval ...) which doesn't do what you want, but as
a side-effect it DOES set the value of SAMPLE_TARGET_NUMBERS.  Thus when
you later run the $(info ...) it looks correct, because now that
variable is assigned.

If you change the makefile so that it runs the $(info ...) FIRST, before
the $(eval ...), then you'll see the problem more clearly.

If your evaluated string contains side-effects (and really, which
don't?) then you must be sure to generate the debugging output BEFORE it
is evaluated, otherwise the output might be misleadingly different from
what make sees when it evaluates.

The concept of the "expansion" target is adding (IMO) unnecessary
complexity here.  Instead of creating a new target which rewrites a new
makefile with extra quoting, running make on that, etc. you can just set
a variable to either print the debug info or not:

    $(if $(DEBUG),$(info $(call template,SAMPLE)))
    $(eval $(call template,SAMPLE))

Now if you run your makefile normally nothing is printed; if you run it
with DEBUG=1 then you'll see what make will evaluate.

In this case you'll see that the entire target_assignments section for
SAMPLE_BIN3_OBJECT_FILES is missing, because the value of
SAMPLE_TARGET_NUMBERS is empty when the for-loop is evaluated.