Re: local variable in make

[Paul Smith]

On Mon, 2010-08-09 at 21:13 -0500, Peng Yu wrote:
> Are you considering adding the local variable feature to macros? I
> know that it may not easy to implement such feature in a backward
> compatible way. But having such feature helps writing more complex and
> more flexible Makefiles.

No, I'm not considering it.  Certainly if it were done it would be done
as a generic scoping capability for makefiles, and not something
specific to macros.

There have been some threads discussing this and describing the
complexity and problems with it.  I've never seen a problem where the
existing alternatives were sufficiently complex that they justified
implementing variable scoping, with all _it's_ complexities.

> I found the following way of defining PREFIX as a macro that takes an
> argument ($1).

> .PHONY: all
> define myfun
> PREFIX=$$(patsubst %,%,$$(1))
> all$1:
>       echo all:$$(call PREFIX, $1)
> endef

I can't think of ANY situation, no matter how complex, in which the
above would work but simply using $1 directly won't.

> But I'm not how to define an PREFIX as an macro that doesn't take an
> argument. (The following doesn't work)

A macro that doesn't take an argument is just a variable, obviously.

$(call PREFIX) is exactly identical to $(PREFIX).

> define myfun
> PREFIX=$$1
> all$1:
>       echo all:$$(call PREFIX)
> endef

Just think about what this expands to... it makes no sense whatsoever.

> The complexity of the usage eval probably should be better expanded in
> the manual. The current explanation of eval in the manual is probably
> too sparse, considering that there could be many tricks in using eval
> for high-order programming (just as eval in Lisp and Perl).

I'm not interested in documenting lots of contorted tricks in the GNU
make manual, though.  The reason there aren't more examples in the
manual is that there are very few use cases for eval that can be
explained in a standard user's manual.  Virtually everything you'd want
to do can be done more quickly, easily, and understandably with other
features in make.  Why would we artificially increase to complexity of
the examples, just to use eval?  That doesn't help anyone write better
makefiles.

> > Alternatively you could use target-specific variables but it seems like
> > overkill.
> 
> Yes, that is the reason that I am looking for some walkaround for
> 'local' variables.

What I meant is, it's overkill based on the example you provided.
However, if your real use-case is really SO complex that none of the
more straightforward alternatives we've suggested are appropriate, and
you MUST have variables set on a per-target basis as you've described,
then target-specific variables are the perfect solution.  That's why
they were created, after all.  They're certainly much simpler to use and
understand than eval.

> >>> Alternatively you could use target-specific variables but it seems like
> >>> overkill.
> >>
> >> Yes, that is the reason that I am looking for some walkaround for
> >> 'local' variables.
> >
> > I don't get it.  "I'm looking for a workaround for my problem.  This
> > is a workaround, but I don't want to use it."  ?
>
> Because this walkaround don't cover corner cases. What if you have
> special variables that are not allowed in targets in the $1? Something
> like the following won't work.
> 
> all$1:

I think you're misunderstanding what we mean by target-specific
variables.  Look them up in the GNU make manual.  Your comments about
corner cases here don't make any sense: you yourself were using $1 in
the target so if the value of $1 might have special characters that are
not valid in targets then you already have this problem... and this
problem cannot be avoided simply by adding a new layer of evaluation.

A solution using target-specific variables would be something like this:

        define myfun
        all$1: PREFIX = $1
        all$1:
                echo all:$$(PREFIX)
        endef

This is still over-engineered though, IMO: just using $1 is much better.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.mad-scientist.net
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist