From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
git@vger.kernel.org,
"Carlo Marcelo Arenas Belón" <carenas@gmail.com>,
"Jonathan Nieder" <jrnieder@gmail.com>
Subject: Re: [PATCH] Makefile: make COMPUTE_HEADER_DEPENDENCIES=auto work with DEVOPTS=pedantic
Date: Wed, 22 Sep 2021 11:28:38 -0700 [thread overview]
Message-ID: <xmqqzgs479d5.fsf@gitster.g> (raw)
In-Reply-To: <YUtiNuUiBU4Xg4gw@coredump.intra.peff.net> (Jeff King's message of "Wed, 22 Sep 2021 13:04:54 -0400")
Jeff King <peff@peff.net> writes:
>> I wonder if the attached (with clean-up to remove the tracing cruft)
>> would show us a better direction. It feeds a single line
>>
>> int dummy_for_dep_check;
>>
>> C "program" from the standard input of the compiler to tackle the
>> "you are not supposed to be compiling an empty compilation unit"
>> problem in a more direct way.
>
> That feels a bit like we're playing a game of chicken with the compiler
> in terms of what it may complain about. For example, sparse will
> complain:
>
> foo.c:1:5: warning: symbol 'dummy_for_dep_check' was not declared. Should it be static?
>
> Might compilers ever learn to warn of the same thing?
Certainly. That is the reason why I said "direction", not
"solution", and I do not think it is beyond our capability to come
up with a minimal "C program" that would be lint clean to make it
as a part of the "solution".
For example, would sparse or compilers complain about this?
extern int incr(int); int incr(int i) { return i + 1; }
> So I'd argue we should go even simpler, like:
>
> diff --git a/Makefile b/Makefile
> index 3628d14f16..4597a126d0 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1277,7 +1277,7 @@ COMPUTE_HEADER_DEPENDENCIES = auto
> endif
>
> ifeq ($(COMPUTE_HEADER_DEPENDENCIES),auto)
> -dep_check = $(shell $(CC) $(ALL_CFLAGS) \
> +dep_check = $(shell $(CC) \
> -c -MF /dev/null -MQ /dev/null -MMD -MP \
> -x c /dev/null -o /dev/null 2>&1; \
> echo $$?)
I am all for this simplification. It takes us back to the state
before 1816bf26 (Makefile: Improve compiler header dependency check,
2011-08-30). But I think that is more or less orthogonal to the
"you are not supposed to feed an empty compilation unit" issue.
> I'm also tempted by a hunk like this. Then we can set the REQUIRE flag
> in a CI job (or locally for git devs who know they have gcc) and notice
> an unexpected breakage in the auto test.
>
> @@ -1295,6 +1295,9 @@ ifneq ($(COMPUTE_HEADER_DEPENDENCIES),no)
> $(error please set COMPUTE_HEADER_DEPENDENCIES to yes, no, or auto \
> (not "$(COMPUTE_HEADER_DEPENDENCIES)"))
> endif
> +ifdef REQUIRE_COMPUTE_HEADER_DEPENDENCIES
> +$(error computed header dependencies required, but auto-check did not find them)
> +endif
> endif
Yup, I like that, too.
next prev parent reply other threads:[~2021-09-22 18:28 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-22 10:38 [PATCH] Makefile: make COMPUTE_HEADER_DEPENDENCIES=auto work with DEVOPTS=pedantic Ævar Arnfjörð Bjarmason
2021-09-22 10:55 ` Carlo Arenas
2021-09-22 11:04 ` Ævar Arnfjörð Bjarmason
2021-09-22 16:08 ` Junio C Hamano
2021-09-22 17:04 ` Jeff King
2021-09-22 18:28 ` Junio C Hamano [this message]
2021-09-22 18:44 ` Carlo Arenas
2021-09-22 20:17 ` Jeff King
2021-09-22 20:36 ` Carlo Arenas
2021-09-22 22:40 ` Ævar Arnfjörð Bjarmason
2021-09-23 17:32 ` Jeff King
2021-09-23 0:03 ` Junio C Hamano
2021-09-23 16:20 ` Jeff King
2021-09-23 17:41 ` Junio C Hamano
2021-09-22 19:45 ` Ævar Arnfjörð Bjarmason
2021-09-22 22:08 ` [PATCH v2 0/2] Makefile: "pedantic" fallout on .depend and "compdb" Ævar Arnfjörð Bjarmason
2021-09-22 22:08 ` [PATCH v2 1/2] Makefile: make COMPUTE_HEADER_DEPENDENCIES=auto work with DEVOPTS=pedantic Ævar Arnfjörð Bjarmason
2021-09-22 22:08 ` [PATCH v2 2/2] Makefile: pass -Wno-pendantic under GENERATE_COMPILATION_DATABASE=yes Ævar Arnfjörð Bjarmason
2021-09-23 0:05 ` Carlo Arenas
2021-09-23 21:33 ` Junio C Hamano
2021-09-23 17:38 ` [PATCH v2 0/2] Makefile: "pedantic" fallout on .depend and "compdb" 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=xmqqzgs479d5.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=avarab@gmail.com \
--cc=carenas@gmail.com \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
--cc=peff@peff.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).