RE: Pattern Specific Variable Limitation

[Matthew Von-Maszewski]

Yep, my case is light against the history of the tool.

You and I could argue all day about interpretations of "equally applicable"
and "order in which pattern rules appear".  You read this a firm requirement
definition.  I read it as fuzzy.  But the bottom line is what is in the
code.

I do appreciate your time spent in reviewing and discussing this change.

Thanks,
Matthew


-----Original Message-----
From: Paul D. Smith [mailto:address@hidden Behalf Of
Paul D. Smith
Sent: Monday, March 19, 2001 9:50 AM
To: Matthew Von-Maszewski
Cc: address@hidden
Subject: RE: Pattern Specific Variable Limitation


%% "Matthew Von-Maszewski" <address@hidden> writes:

  mv> I understand your concern.  What is the impact to older makefiles
  mv> if this change is implemented?

There are more issues than this, too:

 1) Difference in behavior with other pattern rules.  The way "normal"
    pattern rules are handled well-known and well-documented in the
    manual: the rules are processed in order of definition, and each one
    is tried in that order.

    Since target-specific patterns look and feel like "normal" patterns,
    having them behave differently in this respect is not something to
    take lightly.

 2) Flexibility: if you keep an order definition then people can do what
    they want either way by changing the order.  If the change you
    suggest is made, then there is no way to get the "old" behavior back
    again, if that's what you want.

  mv> I did stop and re-read the gnu make documentation on patterns.

The GNU make manual says:

 >    The order in which pattern rules appear in the makefile is important
 > since this is the order in which they are considered.  Of equally
 > applicable rules, only the first one found is used.

("Introduction to Pattern Rules").  By "equally applicable" here they
mean "rules whose targets match the pattern, and whose prerequisites can
be created".

Obviously this is talking about pattern rules themselves, not
target-specific pattern rules, but my point is that having different
behavior between them is potentially confusing.

  mv> - for best match: would create more flexibility for included
  mv>   makefiles (my problem), rules are processed in order of
  mv>   dependency (not sequence), recursively expanded variables are
  mv>   processed at time of need (not sequence of assignment)

I don't understand your last point here?

  mv> From the standpoint of "all that makes make special", I would
  mv> argue for the change.  I never think of a makefile as a sequential
  mv> piece of code.

This view of makefiles as non-programmatic is not _entirely_ correct,
though.  Certainly when walking the dependency graph the ordering has
nothing to do with the makefile, as it should be.  However, many parts
of make _do_ depend on the order of definition in the makefile.  I
quoted the manual above, and there are variable definitions, etc. as
well.

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