help-make
[Top][All Lists]
Advanced

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

RE: Pattern rule prereqs are variables with % in them


From: Paul D. Smith
Subject: RE: Pattern rule prereqs are variables with % in them
Date: Tue, 6 Sep 2005 16:06:56 -0400

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

  bj> I hoped that, since section 3.9 "How make Reads a Makefile" says
  bj> "During the first phase it ... internalizes all the variables and
  bj> their values, implicit and explicit rules, and constructs a
  bj> dependency graph of all the targets and their prerequisites", it
  bj> would be able to treat the "%.lib: $(%.lib_objs)" pattern rule
  bj> just like it does the "%.o: %.c" pattern rule, and translate the
  bj> $(%.lib_objs) variable only when it needed to, ie: when it had the
  bj> target name that matched the "%.lib" pattern.

No.  The manual clearly states that all variable and function references
in the prerequisites list are expanded immediately.

  bj> I don't see why it wouldn't be able to do that.  I guess it's not
  bj> that it can't, but just that it hasn't been done, and that I
  bj> should look at this as an opportunity to finally be able to give
  bj> back something useful to the open source community by implementing
  bj> this behavior as an enhancement to Make. Do you agree with me that
  bj> this would be a valuable addition to how Make handles variables?

Well, you'll have to describe exactly what the modified behavior would
be.  Saying that expansion of variables and functions that appear in a
pattern rule's prerequisite list should be deferred in general is
_clearly_ not acceptable; consider:

    DIR = foo

    %.x : $(DIR)/%.y

    DIR = bar

This will behave completely differently with your change.

If you want to change the behavior so that only variable references
containing pattern characters (%) are not expanded then I would say two
things: first: gross!! :-), and second: it's perfectly legal for
variable names in GNU make to have % in them; how would you handle:

    %FOO = foo
    %.x : $(%FOO)/%.y

  bj> Alternatively, can you recommend any other way to derive the
  bj> prerequisite list from the target that caused this rule to be hit?

Generally in "traditional" GNU make you just write it differently.
Instead of this:

    all: foo.x foo.x

    foo_OBJS = foo.o bar.o baz.o boz.o
    bar_OBJS = b1.o b2.o b3.o

    %.x : %.y $(%_OBJS)

(which as you've discovered doesn't do what you want) you would write it
like this:

    all: foo.x foo.x

    foo.x : foo.o bar.o baz.o boz.o
    bar.x : b1.o b2.o b3.o

    %.x : %.y

So, instead of setting variables you just define the prerequisites
themselves.


In the latest beta versions of GNU make there's a new feature which
allows "double expansion" in prerequisite lists.  With this feature the
prerequisite list is expanded once when it's read in, just as today, but
then it's expanded AGAIN later.  In the second pass we still don't
replace "%" the way you want BUT the automatic variables are available.
So if you escape the expansion from the first pass you can use them,
like this:

    all: foo.x foo.x

    foo_OBJS = foo.o bar.o baz.o boz.o
    bar_OBJS = b1.o b2.o b3.o

    %.x : %.y $$($$*_OBJS)

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




reply via email to

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