[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Last patch reviewed.

From: Boris Kolpackov
Subject: Re: Last patch reviewed.
Date: Thu, 13 Sep 2007 15:12:56 +0000 (UTC)
User-agent: nn/6.7.3

Hi Paul,

A few comments, if I may:

Paul Smith <address@hidden> writes:

> For the former, I think we need to allow the syntax $(::var) which
> returns the global value of the variable "var", for consistency.  This
> could be useful in some situations, as well.  Also, I wonder if it would
> be useful to allow variables to be _SET_ using this syntax.  Then you
> could write something like:
>       somefile::VARIABLE = foo
> which is the same thing, syntactically, as:
>       somefile: VARIABLE = foo
> This would be tricky to add into the parser, though, and maybe it's not
> worth it.

Why not change the "get" syntax to be $(somefile: VARIABLE) instead
of $(somefile::VARIABLE)? This way:

1. The "set" syntax is already there.

2. From the backwards-compatibility standpoint, 'somefile: VARIABLE'
   is a very unlikely existing valiable name, more so than

> The only thing I can think that this would allow is to use
> define/enddef with target-specific variables, which is currently not
> straightforward (you have to define a different variable globally, then
> set the target-specific variable to that value).

Yes, it would be great if this is handled properly, e.g.,

somefile: define foo
        @echo one
        @echo two

> For the latter (inheritance inhibition), there are a few things.  First,
> I think the name of the token should be changed from "not-inherit" to
> "local".  Naming things in the negative ("I am not this" instead of "I
> am this") is something we want to avoid.

While I agree "not-inherit" is a bad keyword, "local" has a bit
different connotation, as being opposite to "global". And GNU make
already has an opposite to "global" which is "target specific".
Maybe "private"? In this case we can say that a variable is
private to a particular context (global, or target-specific) and is
not "inherited" by other contexts.

> Second, it should be valid to mark even global variables "local",
> for consistency.

Can't ask for a better illustartion of my previous point ;-).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]