From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: "Carlo Marcelo Arenas Belón" <carenas@gmail.com>
Cc: git@vger.kernel.org, levraiphilippeblain@gmail.com
Subject: Re: [PATCH] Makefile: avoid breaking compilation database generation with DEPELOPER
Date: Thu, 23 Sep 2021 02:55:36 +0200 [thread overview]
Message-ID: <87tuic5cdo.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <20210922183311.3766-1-carenas@gmail.com>
On Wed, Sep 22 2021, Carlo Marcelo Arenas Belón wrote:
> 3821c38068 (Makefile: add support for generating JSON compilation
> database, 2020-09-03), adds a feature to be used with clang to generate
> a compilation database by copying most of what was done before with the
> header dependency, but by doing so includes on its availability check
> the CFLAGS which became specially problematic once DEVELOPER=1 implied
> -pedantic as pointed out by Ævar[1].
>
> Remove the unnecessary flags in the availability test, so it will work
> regardless of which other warnings are enabled or if the compilers has
> been told to error on them.
>
> [1] https://lore.kernel.org/git/patch-1.1-6b2e9af5e67-20210922T103749Z-avarab@gmail.com/
>
> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
> ---
> Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index 9df565f27b..d5c6d0ea3b 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1302,7 +1302,7 @@ GENERATE_COMPILATION_DATABASE = no
> endif
>
> ifeq ($(GENERATE_COMPILATION_DATABASE),yes)
> -compdb_check = $(shell $(CC) $(ALL_CFLAGS) \
> +compdb_check = $(shell $(CC) \
> -c -MJ /dev/null \
> -x c /dev/null -o /dev/null 2>&1; \
> echo $$?)
Sorry about the overlap in
https://lore.kernel.org/git/patch-v2-2.2-6b18bd08894-20210922T220532Z-avarab@gmail.com/;
I didn't see this thread before sending my version.
I think your patch here is better than mine. FWIW I also had this on top
of mine, i.e. emitting output to stderr unconditionally:
https://github.com/avar/git/commit/d4bcc0e617e52df803870df29df82aa3b2205d84
But thinking about it again I think with the rationale in that
not-on-list commit of mine the below is better than either of our
versions v1.
I.e. for COMPUTE_HEADER_DEPENDENCIES the point of the test is that we
turn it on automatically, so it needs to not suck by default. The reason
we're doing this is, per the comment in 3821c38068:
If this variable is set, check that $(CC) indeed supports the `-MJ`
flag, following what is done for automatic dependencies.
Anyone using GENERATE_COMPILATION_DATABASE is turning it on explicitly,
and I daresay if they're using it at all they're either not using
anything but clang, or is keenly aware of the difference.
So do we really need to carry those 17 lines of the Makefile logic
simply to avoid showing this error on say "CC=gcc
GENERATE_COMPILATION_DATABASE=yes":
gcc: error: unrecognized command-line option ‘-MJ’; did you mean ‘-J’?
It doesn't seem worth it to me, especially as we document that we'll use
the "-MJ" flag in the Makefile comment that the person turning on
GENERATE_COMPILATION_DATABASE=yes must have read.
Anyway, I'll leave you to do what you think is best here, and I'm also
fine with just going for the v1 you've got here, it just seems to me
like we're both fixing logic that's been copy/pasted from
COMPUTE_HEADER_DEPENDENCIES, and the reasons we need it for that
facility don't apply at all to GENERATE_COMPILATION_DATABASE.
-- >8 --
diff --git a/Makefile b/Makefile
index 9df565f27bb..32538f9e858 100644
--- a/Makefile
+++ b/Makefile
@@ -1301,23 +1301,6 @@ ifndef GENERATE_COMPILATION_DATABASE
GENERATE_COMPILATION_DATABASE = no
endif
-ifeq ($(GENERATE_COMPILATION_DATABASE),yes)
-compdb_check = $(shell $(CC) $(ALL_CFLAGS) \
- -c -MJ /dev/null \
- -x c /dev/null -o /dev/null 2>&1; \
- echo $$?)
-ifneq ($(compdb_check),0)
-override GENERATE_COMPILATION_DATABASE = no
-$(warning GENERATE_COMPILATION_DATABASE is set to "yes", but your compiler does not \
-support generating compilation database entries)
-endif
-else
-ifneq ($(GENERATE_COMPILATION_DATABASE),no)
-$(error please set GENERATE_COMPILATION_DATABASE to "yes" or "no" \
-(not "$(GENERATE_COMPILATION_DATABASE)"))
-endif
-endif
-
ifdef SANE_TOOL_PATH
SANE_TOOL_PATH_SQ = $(subst ','\'',$(SANE_TOOL_PATH))
BROKEN_PATH_FIX = 's|^\# @@BROKEN_PATH_FIX@@$$|git_broken_path_fix "$(SANE_TOOL_PATH_SQ)"|'
prev parent reply other threads:[~2021-09-23 1:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-22 18:33 [PATCH] Makefile: avoid breaking compilation database generation with DEPELOPER Carlo Marcelo Arenas Belón
2021-09-22 18:45 ` Eric Sunshine
2021-09-22 18:57 ` [PATCH v2] Makefile: avoid breaking compilation database generation with DEVELOPER Carlo Marcelo Arenas Belón
2021-09-22 19:07 ` Philippe Blain
2021-09-23 1:41 ` brian m. carlson
2021-09-23 1:59 ` Carlo Arenas
2021-09-23 2:08 ` Ævar Arnfjörð Bjarmason
2021-09-23 0:55 ` Ævar Arnfjörð Bjarmason [this message]
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=87tuic5cdo.fsf@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=carenas@gmail.com \
--cc=git@vger.kernel.org \
--cc=levraiphilippeblain@gmail.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 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).