RE: Pattern rule prereqs are variables with % in them

[Paul D. Smith]

%% "Boucher, Jean" <address@hidden> writes:

  bj> I didn't think one would normally use the '%' character in a
  bj> variable, and that Make would discourage it. I tend to limit my
  bj> variables names to use alphanumeric characters and '_', thinking
  bj> others are usually some sort of operator.

There are very few characters which are not valid in a variable name in
GNU make: whitespace, ":", "=", and "$" are about the only ones that are
problematic.

Although special characters aren't common they're not unheard of.  For
example because make doesn't have name spaces for variables, many people
who create generic makefiles prefix "internal" variables with special
characters so they don't collide with per-directory makefiles.

  bj> I'm not suggesting all variable and function references be
  bj> deferred, just those that are part of a static pattern rule
  bj> (again, as is the case for '%.o: %.c' rules) and only those parts
  bj> of a static pattern rule that are affected by the '%'.

My problem with this is it creates a special situation where expansion
of some kinds of variables is handled very differently than other
kinds.  In general I don't like special handling like this.

Also, there are even more complexities that you haven't discussed yet:
what if the "%" is not in the variable name itself, but rather is in a
reference to a variable?

For example:

    MY_TARGETS = $(FOO%BAR) $(BAR%BAZ)

    %.x : $(MY_TARGETS)

??  And of course the reference could be many levels deep.  Make's
evaluation code doesn't provide for "stopping" in the middle of an
evaluation.  You pass it a string and you get back a fully-evaluated
result.  There's no way (currently) to stop in the middle.

As you can see, it just gets more and more confusing.

  bj> In other words, _evaluation_ of the entire prereqs portion of
  bj> pattern rules must always be deferred until they are needed to
  bj> update the target, right?

Correct.

  bj> If that's true, can't you just defer the evaluation of all
  bj> variables in the prereq portion of a rule until that rule is hit
  bj> by a target?

Yes, it _could_ have been defined that way (although that would make
patterns very different from other rules, which is why it wasn't done).

  bj>   foo.elf : foo.o bar.o baz.o boz.o
  bj>   bar.elf : b1.o b2.o b3.o
  bj>   %.elf:
  bj>           echo 'Hit .elf pattern rule for $@';\

Knowing the list inside the command script is no problem: that's what
automatic variables are for (see $^ for example).

  bj> From what you mention about "double expansion" in the latest beta,
  bj> it sounds like the escaped '$*' in the prereq section would do
  bj> something similar to '%', although I'm not sure exactly when you
  bj> mean by "later".  What triggers them to be re-evaluated? Is it at
  bj> the same time the prereqs of static pattern rules are evaluated
  bj> (in the second phase when the rule is actually executed for each
  bj> particular target?

You're mixing things up a little when you speak about static pattern
rules and pattern rules.  Although the names don't reflect it, a static
pattern rule is MUCH closer in behavior to an explicit rule than a
pattern rule.  In fact, make will resolve static pattern rules as the
makefile is read in, turning them into a bunch of explicit rules.  Only
for normal pattern rules is evaluation deferred until later.

Anyway, the secondary expansion for pattern rules works by having the
"escaped" variables and functions evaluated when make is searching for a
matching pattern, yes.

  bj> Will we also be able to defer user-defined variables by escaping
  bj> them this way, or is this just for automatic variables?

All variables and functions can be deferred.  However, it really makes
the most sense when dealing with automatic variables in some way.

  bj> Is CVS on Savannah the only way to get my hands on that latest
  bj> beta?

You can get a recent version of code here:

    ftp://alpha.gnu.org/gnu/make/make-3.81beta3.tar.gz

There are a number of bug fixes in the CVS version that have been made
since that beta was released, though.

  bj> Better yet, when do you think the official release (3.81, I guess)
  bj> will be available?

I can't say.  I hope very soon.  But I've been saying that for 6 months
now.  New problems have been coming up consistently which I think need
to be addressed before the release.

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