RE: Pattern Specific Variable Limitation

[Matthew Von-Maszewski]

Hmm,

I understand your concern.  What is the impact to older makefiles if this
change is implemented?  I would assess the impact as follows:

1. User worked around the bug:  by changing the order of the rules, a user
can get around the limitation.  These users would not be effected by this
change.

2. User unaware that more specific patterns are "filtered" by less specific
patterns:  Wow.  This could be interesting.  This suggests they either have
code that is building wrong, or could unmask older statements that never
worked (hence, never corrected).


I did stop and re-read the gnu make documentation on patterns.  No where
does it explicitly say how the rules would be applied in this case.  At
minimum, I recommend you update the documentation with whatever decision you
make.  I also reread the IEEE Posix description.  Pattern rules do not
appear in the standard I have.  Again the issue is ambiguous.

Arguments:
- for sequence:  maintain historical characteristics, prerequisites get
processed in sequence, simply expanded variables are processed in sequence

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

>From a safety and compatibility standpoint, I would agree to not change.

>From the standpoint of "all that makes make special", I would argue for the
change.  I never think of a makefile as a sequential piece of code.  That is
what I love.  I think of the makefile as a collection of rules, in any
order, that the make tool then resolves into the correct order based upon
the current conditions.  This why dual processor mode (-j2) works so
beautifully (just think about scripting a dual processor mode shell script
...).  The current implementation implies that order is now essential in a
tool that is based upon being order independent.

Thanks for your consideration,
Matthew

-----Original Message-----
From: Paul D. Smith [mailto:address@hidden Behalf Of
Paul D. Smith
Sent: Sunday, March 18, 2001 10:35 PM
To: Matthew Von-Maszewski
Cc: address@hidden
Subject: Re: Pattern Specific Variable Limitation


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

  mv> I found a small, but in my case defeating, limitation with the
  mv> Pattern Specific Variable code.  The code finds the first match
  mv> for a pattern, not necessarily the most specific match.

I'll have to think about this change.  In all the other pattern rules in
make, the first appropriate match always wins; nowhere else in make
does it do any kind of "best fit" match such as you are proposing here.

  mv> Please let me know if you believe this to be a properly formed
  mv> patch.

Actually, not :).  It _would_ help if you could provide a proper patch.

First, the order of arguments to diff is "diff <old> <new>"; you have
used "diff rule.c rul.org" which I interpret to be "diff <new> <old>",
so your diff is backwards (showing lines removed that were really added
and added that were really removed).

Also, any diff created for the purpose of patch should use either the -c
(context) or -u (unified) diff format; these forms include 3 lines of
unchanged text around the actual changes which allows patch to be much
more accurate about finding the right chunk of code to apply the changes
to.  I have a preference for -u, others prefer -c; it doesn't really
matter.

Thanks.

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