Re: Variable definition in eval'd function

[Philip Guenther]

On Jan 2, 2008 9:59 PM, Bryan Ischo <address@hidden> wrote:
> [Sorry if this is a re-send, I wasn't subscribed to address@hidden the
> last time I tried to send it, and I am not sure if my previous version is
> going to get through]

[I suspect your original attempt is awaiting moderator approval;
hopefully the moderator will see that you subscribed and resent]

...
> I think that GNU Make could be improved in three ways to make all of this
> *much* easier:
>
> 1. Replace $(eval $(call)) with a single $(calleval) function which does
> both the template text replacement of $(call) and the GNU Make syntax
> processing of $(eval) at the same time (and I would go one step further
> and just name the function $(eval), completely replacing the functionality
> of the existing $(eval) and eliminating the $(call) function entirely from
> GNU Make).

I can only conclude that you haven't looked at very many examples of
makefiles using $(call).   I suggest you take a look at the "GNU Make
Standard Library" found at http://gmsl.sf.net and examine closely the
uses of $(call) therein.  Please explain how you would define a
recursive function like 'reverse' if there was only your version of
$(eval) and no $(call).

Please also explain how to translate the following makefile to work
with your proposed behavior:
-------
pathsearch = $(firstword $(wildcard $(addsuffix /$(1),$(subst :, ,$(PATH)))))
map = $(foreach a,$(2),$(call $(1),$(a)))

all:
        echo $(call map,pathsearch,ls echo find)
------

(The 'pathsearch' and 'map' functions above come straight from the
section in the GNU make info pages that describes $(call))


> 2. Have GNU Make automatically handle the result of any $(calleval) as
> makefile text to be further parsed and handled by GNU Make, instead of
> generating an error or ignoring the text.

This appears to be exactly the same as your first request.


> 3. Change the way that variables are handled in rules; I'm still pretty
> confused on this but I do know that the way that GNU Make (it inherited
> this behavior from the original make) handles variables in rule commands
> is counterintuitive; they don't end up getting replaced until the very
> last step, when the rule is actually applied, which means that this
> doesn't work like you'd think it would:
>
> VARIABLE=foo_variable
> .PHONY: foo
> foo:
>      @echo $(VARIABLE)
> VARIABLE=bar_variable
> .PHONY: bar
> bar:
>      @echo $(VARIABLE)

If you want target-specific variables, then use target-specific variables!

foo: VARIABLE = foo_variable
bar: VARIABLE = bar_variable
.PHONY: foo bar
foo bar:
        @echo $(VARIABLE)

What, did you not read about those in the info pages?


> The reason being that VARIABLE isn't substituted with its current value
> every time the makefile syntax defining the rules is encountered; but
> instead it is substituted when the rules are being post-processed (at the
> time that they are used during the actual execution of the makefile I
> believe, not during the parsing phase), and VARIABLE already has its final
> value.  I think that this behavior is totally degenerate; one can always
> fix the value of a variable to be the same in two different rules by using
> a variable that is only assigned once and not changed between rules; but
> when one changes a variable's value between rules, I can't think of any
> reason to have done that *except* for the new value to be used in
> subsequent rules.  I understand that changing this behavior would break
> badly-written makefiles, but perhaps a flag could be passed to GNU Make to
> cause it to use the new semantics, and hopefully someday, a switch over to
> making the new semantics the default.

So, without making a complete analysis of its effects, you want to
make a major change to the semantics of makefiles.  Furthermore,
you're willing to label any makefile whose behavior is changed by this
as "badly-written".  Nice.

As for having a switch to provide both semantics:
1) cool, so for each makefile I have to chase down whether it needs this switch?
2) I don't think you have a grasp on the level of complexity your suggestion
    would add to the GNU Make source.


> I think that would be much more logical, and that correspondingly more
> complex GNU Make files would benefit even more (remember that my example
> here was a very simple one!  complex GNU Makefiles using $(eval) and
> $(call) extensively can get very hairy indeed!).

And many of them would be much *more* complex with your change than
they are now.  But you haven't completed the analysis which would show
you that.


Now, you're perfectly free to hack your copy of the GNU make sources
to give it the behavior you desire.  I have no problems with that at
all.  What seems unwise to me is to then suggest that such a program
should call itself 'make'.  It does not behave the way described in
all the existing books on 'make', it does not follow the published
standards for how 'make' should behave on UNIX systems, and it will
mishandle many existing makefiles.  Introducing a gratuitous
incompatibility into a system utility just because you find the
current behavior illogical seems like a *really* bad idea.


Philip Guenther