Re: [bug #39943] Add an alternative parsing mode that regards space and tab as identical tokens

[Reinier Post]

On Thu Sep  5 08:18:51 2013, address@hidden (Paul Smith) wrote:
> On Thu, 2013-09-05 at 11:43 +0100, Tim Murphy wrote:
> > The detection also appears to only work if the statement has a syntax
> > error in it.
> 
> Correct.  If make can understand what the line is (it's a valid makefile
> syntax), then why would it assume that the programmer may have meant
> something different than what was typed?

It should never make any such assumptions.
It should not change the way in which it interprets makefiles.

I think the right approach is the one used by gcc:
have one or more options that issue warnings
for specific 'code smells'

Examples:

  - a rule target appearing on
    a line that starts with non-TAB whitespace

  - a rule directly followed by
    a line that starts with non-TAB whitespace

  - an assignment with trailing whitespace
    (I've been bitten by this in the past)

A second approach is to add an option that spits out
the input makefile with all whitespace omitted or reduced
to a single space when doing so doesn't make a difference
to make's parser.  Having that option would also help in
constructing pretty-printers for makefiles.

Examples of potentially fishy syntax:

 + a rule target on a line that starts with whitespace
 + a rule without dependencies followed by a line starting with
   whitespace that does not contain an assignment

> We have, since 3.82 was released, a way of avoiding this problem with
> the .RECIPEPREFIX variable.  I think that's the right way forward,
> rather than trying to introduce heuristics based on some idea of "common
> styles", which will invariably be incorrect in some situations.

I'm not sure - such a variable can be deeply hidden.
 
> There are a lot of possible things make could warn about, that it
> doesn't currently.  I just think trying to have make attempt to
> understand the semantics of makefiles (what the programmer "meant") will
> be wrong often enough that it won't be considered useful by most.

The semantics of makefiles are not determined by what the programmer
means, but by how make interprets them. The semantics depend on the
syntax, which is determined by how make parses makefiles.
The syntax is a mess; there's nothing make can do about that now.
Make should not change the semantics or syntax of makefiles,
but it can do more to clarify them; that's what warnings are for.

-- 
Reinier Post
http://www.win.tue.nl/~rp/