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

From: Paul Smith <psmith@gnu.org>
Date: Apr 9, 2024, 20:42 UTC
Message-ID: <95f2454e449cc0126aaa40d2ab08c76b55ee3c31.camel@gnu.org>
In-Reply-To: <xmqqcyqz5sie.fsf@gitster.g>

On Mon, 2024-04-08 at 16:44 -0700, Junio C Hamano wrote:

Show 10 quoted lines

> Paul Smith <psmith@gnu.org> writes:
> 
> > 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.
> 
> I wonder if you could ease the transition by leaving the current
> parsing rule for conditional constructs that are indented with HT
> and clearly mark them as "works as best-effort basis---the parsing
> bug for them may remain",

I'm not sure I understand the suggestion here. If I preserve the current parsing behavior what do I tell people who cannot get their makefiles to work because the current parsing doesn't allow it?

Show 7 quoted lines

> introduce BSD compatible .if/.else and friends, and nudge the users
> in that direction.
> 
> Having to use two different indentation style in the same Makefile
> is simply a nightmare, and that might be a good enough incentive for
> users to move to the new "you can write with dots like .if and that
> way you can continue indenting with HT".

I agree that it's a nightmare, but IMO trying to continue to work around this terrible original sin in make (using TAB as a non- whitespace token) by adding new keywords is the wrong direction.

The right direction is to STOP using TAB as a special token and turn it back into what it is in other languages: simple whitespace.

That was already accomplished back in 2010 in GNU Make 3.82 with the introduction of the .RECIPEPREFIX variable.