Re: [PATCH] Makefile(s): avoid recipe prefix in conditional statements

[Paul Smith <psmith@gnu.org>]

On Mon, 2024-04-08 at 14:41 -0700, Junio C Hamano wrote:
> Taylor Blau <me@ttaylorr.com> writes:
> 
> > When a conditional word (ifeq, ifneq, ifdef, etc.) is preceded by
> > one or
> > more tab characters, replace each tab character with 8 space
> > characters
> > with the following:
> > 
> >      find . -type f -not -path './.git/*' -name Makefile -or -name
> > '*.mak' |
> >        xargs perl -i -pe '
> >          s/(\t+)(ifn?eq|ifn?def|else|endif)/" " x (length($1) * 8)
> > . $2/ge unless /\\$/
> >        '
> 
> Yuck, it means auto indenting Makefile and its pieces almost
> impossible X-<.  I'll take the patch as there is no way to revert
> the change to GNU make, though.

I am considering whether to turn this error into a warning, for the
next release only, since it seems to be causing problems.  I have not
decided for sure yet since the change is needed to avoid a very real
parsing error (see the Savannah bug for details) which then could not
be fixed in this release.

Just to note that this usage clearly contravenes the documentation,
which states that preprocessor statement lines cannot begin with a TAB.
It was a bug that this was allowed by the GNU Make parser.

I understand that in many projects (Linux, probably Git :)) if the
documentation and behavior disagreed then the documentation would be
changed, not the behavior.

I'd love to do that as well but unfortunately there's just no way to
get coherent behavior out of GNU Make if this TAB prefix is allowed. 
If the original authors of GNU Make had followed the lead of the BSD
make folks (or C) and used some reserved character to introduce
preprocessor statements (BSD make uses ".if"/".else" etc. which would
work) then we wouldn't be in this predicament.  But make's parser is so
ad hoc that it's impossible to fix issues like this in a completely
backward-compatible manner.

I know that the coding style in some projects is to use TAB for each
level of indentation, but I do not think it's possible to extend that
same coding style from C into makefiles.  In makefiles, a TAB is not
just whitespace it's a meaningful token and has to be reserved for use
only in places where that meaning is required: to introduce a recipe
line.  Hopefully everyone's editors have the concept of separate modes
for different types of files, with different indentation styles for
each.

My personal recommendation is that you do not take this patch as-is,
and instead request a patch that converts every TAB character that
indents a GNU Make preprocessor statement into TWO spaces rather than
8.  Or even THREE spaces (to avoid indentation that matches a TAB in
width which could cause visual confusion).  However of course that's up
to you all.


If you wanted to make an even bigger change, which might save some
hair-pulling down the road but is a very serious decision, you could
introduce the use of the .RECIPEPREFIX [1] variable to change the
recipe prefix from TAB to some other character (as it should have been
when make was created back in the 1970's).

.RECIPEPREFIX was introduced in GNU Make 3.82, which was released in
2010 FYI.


Again, apologies for the churn... :(


[1] https://www.gnu.org/software/make/manual/html_node/Special-Variables.html#index-_002eRECIPEPREFIX-_0028change-the-recipe-prefix-character_0029