Hi David, Sam, "make headers_check" is too verbose. It likes to chat even if it has just _successfully_ checked a header, and not just on seeing errors. What is worse, even if you touch just one little header in some corner (or possibly none) and type "make" on an "already-made" tree, headers_check still feels obliged to check all the headers.
Both the above things combined mean that when you're working on your own little subsystem, and simply "make" an already-made tree, and turn around to speak to a colleague, then by the time you look back at the screen, it does not contain any useful warnings from the actual compilation stage. If you're unlucky, the entire scroll-back history of the xterm would have also got polluted with headers_check's "CHECK include/linux/foo.h" spam. As a result I've been totally put off by it and have CONFIG_HEADERS_CHECK=n set in my .config -- but that could lead to breakages. Hence: [PATCH] Make headers_check less chatty for success cases We still echo verbosely (and fail, obviously) for any errors encountered. Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]> --- [ just removing that line also works, but that loses symmetry with others ] scripts/Makefile.headersinst | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/scripts/Makefile.headersinst b/scripts/Makefile.headersinst index 53dae3e..0a23dd9 100644 --- a/scripts/Makefile.headersinst +++ b/scripts/Makefile.headersinst @@ -96,7 +96,7 @@ quiet_cmd_unifdef = UNIFDEF $(patsubst $(INSTALL_HDR_PATH)/%,%,$@) cmd_unifdef = $(UNIFDEF) $(patsubst $(INSTALL_HDR_PATH)/$(_dst)/%,$(srctree)/$(obj)/%,$@) \ | $(HDRSED) > $@ || : -quiet_cmd_check = CHECK $(patsubst $(INSTALL_HDR_PATH)/$(_dst)/.check.%,$(_dst)/%,$@) +quiet_cmd_check = cmd_check = $(CONFIG_SHELL) $(srctree)/scripts/hdrcheck.sh \ $(INSTALL_HDR_PATH)/include $(subst /.check.,/,$@) $@ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/