From: Boris Kolpackov <boris@codesynthesis.com>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: linux-kbuild@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
Michal Marek <michal.lkml@markovi.net>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kconfig: drop filename and line number prefix from warning/error-if macros
Date: Mon, 21 Dec 2020 16:22:53 +0200 [thread overview]
Message-ID: <boris.20201221161803@codesynthesis.com> (raw)
In-Reply-To: <20201221094650.283511-1-masahiroy@kernel.org>
[Copying some of my comments from another reply.]
Masahiro Yamada <masahiroy@kernel.org> writes:
> When I implemented the Kconfig macro language, I took the GNU Make
> behavior as a reference in general, but I did not follow the message
> format of $(error ...) to avoid that annoyance.
>
> So, the following code in Kconfig:
>
> $(warning-if,y,This is the first line)
> $(warning-if,y,This is the second line)
> $(error-if,y,This is the last line)
>
> ... will print the messages in a consistent format:
>
> Kconfig:1: This is the first line
> Kconfig:2: This is the second line
> Kconfig:3: This is the last line
IMO, there is a flaw with this approach: there is no way for the
user to know that these three lines are about the same error.
If we want this ability, then let's find a way do it properly
rather than spreading further hacks. For example, in the build
system I am working on, we have suport for multi-line diagnostics
records that to the user look like this:
Makefile:3: error: This is the first line
This is the second line
This is the last line
> But, in hindsight, the built-in functions should have only primitive
> functionality to print the given message without any prefix. The lesson
> I learned from GNU Make was such a prefix is easy to add, difficult to
> remove.
>
> This commit changes the built-in functions, warning-if and error-if, to
> not print the file name or the line number.
Wouldn't automatically showing the position in the Kconfig file
where the error/warning has originated be much, much more useful
than the occasional need to print multi-line messages?
prev parent reply other threads:[~2020-12-21 14:31 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-21 9:46 [PATCH] kconfig: drop filename and line number prefix from warning/error-if macros Masahiro Yamada
2020-12-21 14:22 ` Boris Kolpackov [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=boris.20201221161803@codesynthesis.com \
--to=boris@codesynthesis.com \
--cc=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=michal.lkml@markovi.net \
/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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.