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/
