On Mon, 2024-04-08 at 16:44 -0700, Junio C Hamano wrote: > Paul Smith <psmith@xxxxxxx> 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.
