From: Paul Smith Date: Tue, 09 Apr 2024 20:42:14 GMT Subject: Re: [PATCH] Makefile(s): avoid recipe prefix in conditional statements Message-ID: <95f2454e449cc0126aaa40d2ab08c76b55ee3c31.camel@gnu.org> In-Reply-To: On Mon, 2024-04-08 at 16:44 -0700, Junio C Hamano wrote: > Paul Smith 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? > 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.