On Wed, Nov 25, 2020 at 11:38 PM Boris Kolpackov <boris@xxxxxxxxxxxxxxxxx> wrote: > > I am preparing a set of patches that clean up kconfig diagnostics and > make it more consistent both internally and with respect to other > tools (like compilers). However, a couple of changes that I would like > to make could be controversial so I want to discuss them before wasting > everyone's time with patches: > > 1. Add 'warning' word to $(warning-if) output: > > - fprintf(stderr, "%s:%d: %s\n", ...); > + fprintf(stderr, "%s:%d: warning: %s\n", ...); > > This makes it consistent with the rest of the warnings printed by > kconfig. > > 2. Print $(info) output to stderr instead of stdout. > > I realize the current behavior is consistent with GNU make (on which > it is based) but at the same time it's inconsistent with the rest of > kconfig (#1) or does not seem to make much sense (#2), at least to > me. > > To elaborate on #2, $(info) is still diagnostics, just a different > level compared to $(warning-if) and $(error-if). It's not clear to > me why it should go to stdout. > > If we needed the ability to print something to stdout, we could add > another function, such as $(print). However, I can't think of a good > reason why we would need to; this, for example, has the potential to > mess up with the terminal-based UI (which is written to stdout). > > I've done a search and as far as I can see, neither $(warning) nor > $(info) is currently used anywhere in the kernel outside the kconfig > testsuite. So these changes shouldn't have any backwards-compatibility > issues. > > Thoughts? $(warning-if ...) and $(info ...) mimic $(warning ...) and $(info ...) because the design of kconfig macros was inspired by GNU Make. So, I implemented them in the same way as GNU Make did unless I had a good reason to do otherwise. I expected they would be useful for debugging for something, but there is no actual user. We can change them if there is a reason, but I cannot see it in your description. -- Best Regards Masahiro Yamada
