All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Emily Shaffer <emilyshaffer@google.com>,
	Ramsay Jones <ramsay@ramsayjones.plus.com>
Subject: Re: [PATCH] Makefile: drop GEN_HDRS
Date: Mon, 16 Dec 2019 14:20:14 -0500	[thread overview]
Message-ID: <20191216192014.GA2678964@coredump.intra.peff.net> (raw)
In-Reply-To: <xmqqlfrcje1f.fsf@gitster-ct.c.googlers.com>

On Mon, Dec 16, 2019 at 10:55:40AM -0800, Junio C Hamano wrote:

> LIB_H could contain command-list.h (and other GENERATED_H files) if
> we did this, but dups in dependency does not hurt in general, and I
> did not find anything potentially problematic in the existing use of
> $(LIB_H) in our Makefile.
> 
> How about doing this as a further clean-up?  I am reasonably sure
> the status-quo description is correct, but I find the justification
> a bit weak (in other words, I do not have a good answer to "who
> cares if those that depend on $(LIB_H) are not rebuilt when
> command-list.h gets rebuilt?")

Yeah, I don't think there's any change in behavior here, since with the
exception of hdr-check, every mention of $(LIB_H) also mentioned
$(GENERATED_H). And in the case of hdr-check, we explicitly exclude the
only item found in $(GENERATED_H).

But this would enable us to start checking command-list.h. I'm on the
fence on whether that's useful or not; the patch below makes it pass,
but I'm not sure if that is really turning up any useful problems. I
suppose somebody besides help.c could include command-list.h, in which
case some of those MAYBE_UNUSED bits could become useful.

I actually wonder if the whole thing would be simpler if command-list.h
was a static tracked file with the declarations, and we generated
command-list.c with "extern const char *command_list[]", etc.

> --- >8 ---
> Makefile: include GENERATED_H in LIB_H
> 
> $(LIB_H), which is meant to be the list of header files that can
> affect (hence trigger recompilation) the objects that go in
> libgit.a, in a directory extracted from a tarball is computed by
> running "find \*.h" but instead computed with "ls-files \*.h" in a
> working tree managed by a git repository.  The former can include
> generated header files after a build, and omit them in a clean
> state.  The latter would not, as generated header files are by
> definition not tracked.
> 
> Explicitly add $(GENERATED_H) to $(LIB_H) to make things consistent.

I do think this is slightly simpler to reason about than the existing
setup (though see my "should it just be a C file?" above).

Here's the patch that would make hdr-check work:

---
diff --git a/Makefile b/Makefile
index 87b68962ed..1eac8e7a7a 100644
--- a/Makefile
+++ b/Makefile
@@ -2780,7 +2780,7 @@ $(SP_OBJ): %.sp: %.c GIT-CFLAGS FORCE
 .PHONY: sparse $(SP_OBJ)
 sparse: $(SP_OBJ)
 
-GEN_HDRS := command-list.h unicode-width.h
+GEN_HDRS := unicode-width.h
 EXCEPT_HDRS := $(GEN_HDRS) compat/% xdiff/%
 ifndef GCRYPT_SHA256
 	EXCEPT_HDRS += sha256/gcrypt.h
diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh
index 71158f7d8b..7b0751e3e1 100755
--- a/generate-cmdlist.sh
+++ b/generate-cmdlist.sh
@@ -48,6 +48,7 @@ define_categories () {
 define_category_names () {
 	echo
 	echo "/* Category names */"
+	echo "MAYBE_UNUSED"
 	echo "static const char *category_names[] = {"
 	bit=0
 	category_list "$1" |
@@ -61,6 +62,7 @@ define_category_names () {
 }
 
 print_command_list () {
+	echo "MAYBE_UNUSED"
 	echo "static struct cmdname_help command_list[] = {"
 
 	command_list "$1" |
@@ -78,6 +80,7 @@ print_command_list () {
 
 print_config_list () {
 	cat <<EOF
+MAYBE_UNUSED
 static const char *config_name_list[] = {
 EOF
 	grep -h '^[a-zA-Z].*\..*::$' Documentation/*config.txt Documentation/config/*.txt |
@@ -101,7 +104,8 @@ do
 	shift
 done
 
-echo "/* Automatically generated by generate-cmdlist.sh */
+echo "#include \"gettext.h\"
+/* Automatically generated by generate-cmdlist.sh */
 struct cmdname_help {
 	const char *name;
 	const char *help;

  reply	other threads:[~2019-12-16 19:20 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-13 23:25 [PATCH] Makefile: drop GEN_HDRS Junio C Hamano
2019-12-14  0:38 ` Jeff King
2019-12-14  1:00   ` Jeff King
2019-12-16 18:55     ` Junio C Hamano
2019-12-16 19:20       ` Jeff King [this message]
2019-12-17  1:27         ` Emily Shaffer
2019-12-17  1:40           ` Jonathan Nieder
2019-12-17  5:22           ` Jeff King
2019-12-17  1:43         ` Jonathan Nieder
2019-12-17  5:28           ` Jeff King
2019-12-17 11:35             ` vcxproj target, was " Johannes Schindelin
2019-12-19  4:51               ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191216192014.GA2678964@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=emilyshaffer@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=ramsay@ramsayjones.plus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.