Masahiro Yamada <masahiroy@xxxxxxxxxx> writes: > On Mon, Dec 21, 2020 at 11:05 PM Boris Kolpackov <boris@xxxxxxxxxxxxxxxxx> wrote: > > > If you 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 > > I also thought about this possibility. > > define newline > > > endef > > > $(warning This is first line$(newline) \ > This is the second line$(newline) \ > This is the last line\ > ) Or we could extend these functions to accept additional lines of diagnostics as additional arguments: $(warning This is first line,\ This is the second line,\ This is the last line) > > How is me (as a user) redirecting stderr to a location of > > my choosing and only ending up with half of the diagnostics > > there (with the other half silently overridden by the GUI) > > not problematic? > > This is a hypothetical argument since we have no user of $(info). > $(info) is not a warning. > The change is unneeded. There is no use in the Linux kernel but there could be in other projects that re-use the kconfig machinery. By narrowly focusing only on the kernel's needs to the point of ignoring bugs that are not triggered, you leave such projects no choice but to fork. While this attitude means less work for you in the short term, it also makes authors of such projects less interested in contributing anything back. For example, I have a fix for SIGSEGV sitting in my branch that I have very little incentive to try to upstream since I will now be maintaining other fixes out of tree and one more doesn't really make any difference.
