From: Junio C Hamano <gitster@pobox.com>
To: Paul Smith <psmith@gnu.org>
Cc: Taylor Blau <me@ttaylorr.com>,
git@vger.kernel.org,
Dario Gjorgjevski <dario.gjorgjevski@gmail.com>,
Jeff King <peff@peff.net>
Subject: Re: [PATCH] Makefile(s): avoid recipe prefix in conditional statements
Date: Mon, 08 Apr 2024 16:44:41 -0700 [thread overview]
Message-ID: <xmqqcyqz5sie.fsf@gitster.g> (raw)
In-Reply-To: <606990048585347654f3b4b187ec27f4dc1b85e3.camel@gnu.org> (Paul Smith's message of "Mon, 08 Apr 2024 19:24:16 -0400")
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.
> 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 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", 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".
next prev parent reply other threads:[~2024-04-08 23:44 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-08 10:44 Makefiles are broken as of GNU Make commit 07fcee35f058a876447c8a021f9eb1943f902534 Dario Gjorgjevski
2024-04-08 15:51 ` [PATCH] Makefile(s): avoid recipe prefix in conditional statements Taylor Blau
2024-04-08 21:41 ` Junio C Hamano
2024-04-08 23:24 ` Paul Smith
2024-04-08 23:34 ` Junio C Hamano
2024-04-09 20:41 ` Paul Smith
2024-04-08 23:44 ` Junio C Hamano [this message]
2024-04-09 20:42 ` Paul Smith
2024-04-09 21:23 ` Junio C Hamano
2024-04-09 0:04 ` Jeff King
2024-04-09 0:17 ` Jeff King
2024-04-09 20:44 ` Paul Smith
2024-04-08 23:28 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqcyqz5sie.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=dario.gjorgjevski@gmail.com \
--cc=git@vger.kernel.org \
--cc=me@ttaylorr.com \
--cc=peff@peff.net \
--cc=psmith@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).