[Top][All Lists]

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

Re: Last patch reviewed.

From: Paul Smith
Subject: Re: Last patch reviewed.
Date: Sun, 09 Sep 2007 21:48:55 -0400

On Sat, 2007-09-08 at 17:00 +0200, Ramón García wrote:
> Why nobody noticed?

I was reviewing the older patch; sorry about that.

> By the way, this code has not yet been integrated into GNU make. How
> can I help?

I'm looking at ways to integrate the changes incrementally.  The
entirety seems a bit overwhelming.  I'd like start from the bottom, with
the most obviously correct/useful/generic/etc. features, and work our
way up, making sure each part is well-documented and tested, etc.  Also
some of the user interface I think need to be tweaked, and there are
code cleanups etc. that are needed, both file naming conventions and
coding conventions (I think I mentioned these before but let me know if
you need me to restate).  These can wait (or I can make them myself; no
big deal).

Good places to start, I think, are the evaluation context change (e.g.,
$(targ::var)) and the inheritance inhibition feature.

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.  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).

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.

Second, it should be valid to mark even global variables "local", for
consistency.  If it were set then what does it mean?  For consistency I
think it means that this variable is not inheritable in a
target-specific way.  That in effect means it's only useful for setting
or testing other global variables.  For example:

  local SOMEVAR = global
  foo: ; echo local $(SOMEVAR)

would just print "local", while if the "local" keyword weren't there
before SOMEVAR then it would print "local global".

The only thing I could imagine this would be useful for is some kind of
sanity check, if you wanted to ensure that a variable was not used
inside targets (maybe to ensure that either they get set in a target
specific way, or they're blank--of course leaving them empty would do
the same).

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

reply via email to

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