Semantic strangeness in parsing makefiles

[Paul D. Smith]

I'm almost done with the multi-line expansion feature which is the main
new feature to be introduced in GNU make 3.80.

While doing this I modified, somewhate sanitized, and extensively
documented :), the portion of the reading of makefiles that handles
target definitions.

In so doing, however, I have modified the behavior of make.  I'm looking
into putting it back the way it was, but it's kind of gross.  Also, I
think that the old behavior was not very well defined itself.

There is no mention of this in the GNU make manual that I can see, but
there is one regression test that fails due to the change.


Anyway, here it is:

The current algorithm for expanding rule definition lines in GNU make is
this: take each word on the line and var-expand it.  Then, walk the
expansion of that word looking for ":" or "::" tokens.  If we find one,
that's the first colon for the rule definition.  If there's no colon
there, go to the next word on the line and expand and search that.  If
we get to the end of the line and no colon appears, then it's a missing
separator error (at this point we already know it's not a variable
assignment or preprocessor statement).

The new algorithm is this: look through the _unexpanded_ line, for a ":"
or "::" token.  If we find one, then expand everything to the left of
that and chop it up on whitespace separators into targets.  If no colon
is found, then this line is expanded and pushed back onto the makefile
read stream, and we start over with a new line.

In practice, the only place I can find where the differences between
these two algorithms changes the result is in a situation where one of
the variables in the target list expands to contain a colon:

  FOO = bar:baz

  $(FOO) biz : boz

Current versions of GNU make will parse this as:

  bar : baz biz : boz

where the target is just "bar".  This is actually a syntax error, since
GNU make expects this to be a static pattern rule, but there are no
pattern chars.


The new version of GNU make will parse the above as:

  bar:baz biz : boz

where there are two targets: "bar:baz" and "biz", and one prerequisite,
"boz".


So, what do people think about this?  Is it simpler to understand the
new way, or the old way?  Do you think the old behavior is documented (I
couldn't find it) or standardized enough that there are live makefiles
that use it?

In normal make you'd always get a syntax error AFAICT, since you have
two separate colons on the line.  In GNU make this _could_ be a legal
construct, but it would have to expand to a legal static pattern rule.


I'm willing to fix it to behave as before, if that seems the best, but
there will be some (small) performance penalty involved.  It's just not
clear to me that this older behavior is really specified anywhere, or
even desirable, really.

Comments?

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>    HASMAT--HA Software Methods & Tools
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.