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

[Paul Smith]

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?

That is a road leading directly to frustration and annoyance, in the
other direction.

> e.g.
> fred:
>         X=25;echo$$X
> 
> With 8 spaces the above is not warned about even though to the human
> eye when you use vim's search function to highlight spaces it becomes
> visually highly suspicious.
> 
> 1) it's immediately after a target or
> 2) immediately after a recipe
> 3) it's indented which is an odd thing to do outside of any context such as 
> ifeq

#3 is far too broad.  You are trying to enforce behavior by
extrapolating from your preferred makefile style.

There are widely-used makefile styles where variable assignments are
often indented.  For example, some people use a style where the "=" is
aligned and the variable name is right-justified:

             FOO = bar
     ANOTHER_VAR = biz
        SOME_VAR = baz

Plus, remember that make's syntax is very forgiving of "blank lines"
within recipes, which includes comments.  Consider this makefile:

    KEEP = false

    target:
            @echo command

    # Now we do some other stuff
    ifeq ($(KEEP),true)
    keep:
            @echo keep
    endif

    # and this is something else
            FOO=bar

How does make interpret the "FOO=bar"?  To make, because all the text
between the last "target" recipe line and the assignment is either
removed or are comments, that assigment (if it started with a TAB) would
be considered part of the "target" recipe.  If we start to allow random
whitespace at the beginning of a line to mean "part of a recipe", things
will start to break all over the place in unusual ways.

> I'm not suggesting that there's any truly satisfactory way to be sure
> of this but even if an "info" message appeared or an "NB" or if one
> had to switch on some special warning mode that was extra picky -
> whatever it was would be handy and perhaps discourage people from
> using styles that could end up in confusion.  50 years down the line
> for gmake 5 our children might then switch from notification to
> warning and finally enforcement of something.

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.

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.