On Wed, Dec 2, 2020 at 5:06 PM Boris Kolpackov <boris@xxxxxxxxxxxxxxxxx> wrote: > > Masahiro Yamada <masahiroy@xxxxxxxxxx> writes: > > > We can change them if there is a reason, but I cannot see it in your > > description. > > > Boris Kolpackov <boris@xxxxxxxxxxxxxxxxx> wrote: > > > > > 1. Add 'warning' word to $(warning-if) output: > > This will make the diagnostics consistent with other places in kconfig > where warnings are issued (see conf_warrning() in confdata.c). 'warning:' from C code and $(warning-if) are implemented in different layers. So, I do not think it is necessary to prepend 'warning:'. More importantly, I cannot find a good way to print multiple lines of error messages when $(error ...) is hit. I prefer wrapping a long message in 80-columns. After all, the best way I came up with for GNU Make is to use $(error ) for the last line, and $(warning ) for the rest. $(warning This is the first line) $(warning This is the second line) $(error This is the last line) masahiro@grover:~$ make Makefile:1: This is the first line Makefile:2: This is the second line Makefile:3: *** This is the last line. Stop. This works, except the small flaw, "***". What if GNU Make prepended 'warning:' and 'error:' as you suggest? Makefile:1: warning: This is the first line Makefile:2: warning: This is the second line Makefile:3: error: *** This is the last line. Stop. This is even odd since I just want to split the message into multiple lines. If you want, you can include 'warning: ' in the message, but you would not be able to get rid of it if it were printed by default. So, I do not want to add unwanted prefixes. In a little more thought, I'd rather go opposite; make $(warning-if) and $(error-if) as simple as just printing the given message without any prefix. https://patchwork.kernel.org/project/linux-kbuild/patch/20201221094650.283511-1-masahiroy@xxxxxxxxxx/ > > > > 2. Print $(info) output to stderr instead of stdout. > > There are two reasons: > > 1. Error, warning, and info are different diagnostics levels. It was > surprising to me that the first two go to stderr while info goes > to stdout. For example, as a user, if I redirect stderr, I would > naturally expect all the diagnostics to go there. > > 2. More importantly, stdout is used by terminal-based UI configurators. > So depending on exactly when $(info) is issued, its output could either > be clobbered by UI (so the user won't notice it) or it can clobber UI > (so the user will see broken UI). I do not think this is overly problematic because Kconfig enters the GUI mode after parsing all Kconfig files. Also, if my new patch lands, the format from $(info) and $(warning-if ) will be the same. If we directed the $(info ) to stderr, $(info ) and $(warning-if ) will be completely equivalent, and we will lose the reason to have $(info ). -- Best Regards Masahiro Yamada
