All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Mike Hommey <mh@glandium.org>
Cc: git@vger.kernel.org, "Junio C Hamano" <gitster@pobox.com>,
	"Emily Shaffer" <emilyshaffer@google.com>,
	"Jeff King" <peff@peff.net>, "René Scharfe" <l.s.r@web.de>
Subject: Re: [PATCH 8/8] hook-list.h: add a generated list of hooks, like config-list.h
Date: Mon, 15 Nov 2021 23:49:31 +0100	[thread overview]
Message-ID: <211115.86bl2lqbbt.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <20211115224015.vzfevpvptysxzpaa@glandium.org>


On Tue, Nov 16 2021, Mike Hommey wrote:

> On Mon, Nov 15, 2021 at 11:26:36PM +0100, Ævar Arnfjörð Bjarmason wrote:
>> 
>> On Tue, Nov 16 2021, Mike Hommey wrote:
>> 
>> > On Thu, Sep 23, 2021 at 12:30:03PM +0200, Ævar Arnfjörð Bjarmason wrote:
>> >> -builtin/help.sp builtin/help.s builtin/help.o: config-list.h GIT-PREFIX
>> >> +hook.sp hook.s hook.o: hook-list.h
>> >> +
>> >> +builtin/help.sp builtin/help.s builtin/help.o: config-list.h hook-list.h GIT-PREFIX
>> >
>> > hook-list.h is only included from buitin/bugreport.c, so
>> > builtin/bugreport.o should be the one with the hook-list.h dependency,
>> > shouldn't it?
>> 
>> Well spotted, yes. This is a mistake. I think from some earlier WIP
>> version of the series.
>> 
>> In practice we don't really miss dependencies due to these sorts of
>> mistakes since we use the .depends files, i.e. GCC & Clang figure this
>> out for us:
>> 
>>     $ grep hook-list .depend/* */.depend/*
>>     builtin/.depend/bugreport.o.d: compat/compiler.h git-compat-util.h hook.h hook-list.h
>>     builtin/.depend/bugreport.o.d:hook-list.h:
>
> But aren't those .depends files are only created when compiling object
> files, such that builtin/.depend/bugreport.o.d wouldn't exist until
> bugreport.c is compiled, which would fail if hook-list.h wasn't created
> before that?

Fail how?

I don't think it could fail, because the purpose of these dependency
relationships is to avoid needless *re*builds. So if you're building for
the first time it doesn't matter, your compiler will find the relevant
things to include for you. It doesn't need what's in the Makefile to do
that.

See [1], what I said about LIB_H there applies more generally for the
.depends files.

It will only fail in the sense that it over-depends, i.e. if you do:

    git clean -dxf; make builtin/help.o

We'll generate the hook list, as opposed to for buildin/add.o or
whatever, but I'd say that generally doesn't matter all that much, what
matters is that we don't miss dependency relationships.

Anyway, I'll try to loop around to fixing this, just wanted to gather
some interest in the more general set of fixes I've got. I've got some
fixes queued up after that that fix/improve the *.sp and *.s parts of
the line you quoted (and other similar lines). I'd prefer just to fix
this along with those so the two don't textually conflict.

1. https://lore.kernel.org/git/211110.86h7cki0uo.gmgdl@evledraar.gmail.com/

  reply	other threads:[~2021-11-16  0:16 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-23 10:29 [PATCH 0/8] Makefile: generate a hook-list.h, prep for config-based-hooks Ævar Arnfjörð Bjarmason
2021-09-23 10:29 ` [PATCH 1/8] Makefile: mark "check" target as .PHONY Ævar Arnfjörð Bjarmason
2021-09-23 10:29 ` [PATCH 2/8] Makefile: stop hardcoding {command,config}-list.h Ævar Arnfjörð Bjarmason
2021-09-23 10:29 ` [PATCH 3/8] Makefile: don't perform "mv $@+ $@" dance for $(GENERATED_H) Ævar Arnfjörð Bjarmason
2021-09-23 10:29 ` [PATCH 4/8] Makefile: remove an out-of-date comment Ævar Arnfjörð Bjarmason
2021-09-23 10:30 ` [PATCH 5/8] hook.[ch]: move find_hook() from run-command.c to hook.c Ævar Arnfjörð Bjarmason
2021-09-23 10:30 ` [PATCH 6/8] hook.c: add a hook_exists() wrapper and use it in bugreport.c Ævar Arnfjörð Bjarmason
2021-09-23 10:30 ` [PATCH 7/8] hook.c users: use "hook_exists()" instead of "find_hook()" Ævar Arnfjörð Bjarmason
2021-09-23 10:30 ` [PATCH 8/8] hook-list.h: add a generated list of hooks, like config-list.h Ævar Arnfjörð Bjarmason
2021-09-24 10:19   ` Phillip Wood
2021-09-24 15:51     ` Junio C Hamano
2021-09-24 16:39       ` René Scharfe
2021-09-24 19:30     ` Ævar Arnfjörð Bjarmason
2021-09-24 19:56       ` René Scharfe
2021-09-24 20:09         ` Ævar Arnfjörð Bjarmason
2021-09-27  9:24       ` Phillip Wood
2021-09-27 10:36         ` Ævar Arnfjörð Bjarmason
2021-11-15 22:04   ` Mike Hommey
2021-11-15 22:26     ` Ævar Arnfjörð Bjarmason
2021-11-15 22:40       ` Mike Hommey
2021-11-15 22:49         ` Ævar Arnfjörð Bjarmason [this message]
2021-11-15 23:00           ` Mike Hommey
2021-11-16 12:01             ` Ævar Arnfjörð Bjarmason
2021-11-17  8:39               ` Junio C Hamano
2021-09-26 19:03 ` [PATCH v2 0/8] Makefile: generate a hook-list.h, prep for config-based-hooks Ævar Arnfjörð Bjarmason
2021-09-26 19:03   ` [PATCH v2 1/8] Makefile: mark "check" target as .PHONY Ævar Arnfjörð Bjarmason
2021-09-26 19:03   ` [PATCH v2 2/8] Makefile: stop hardcoding {command,config}-list.h Ævar Arnfjörð Bjarmason
2021-09-26 19:03   ` [PATCH v2 3/8] Makefile: don't perform "mv $@+ $@" dance for $(GENERATED_H) Ævar Arnfjörð Bjarmason
2021-09-26 19:03   ` [PATCH v2 4/8] Makefile: remove an out-of-date comment Ævar Arnfjörð Bjarmason
2021-09-26 19:03   ` [PATCH v2 5/8] hook.[ch]: move find_hook() from run-command.c to hook.c Ævar Arnfjörð Bjarmason
2021-09-26 19:03   ` [PATCH v2 6/8] hook.c: add a hook_exists() wrapper and use it in bugreport.c Ævar Arnfjörð Bjarmason
2021-09-26 19:03   ` [PATCH v2 7/8] hook.c users: use "hook_exists()" instead of "find_hook()" Ævar Arnfjörð Bjarmason
2021-09-26 19:03   ` [PATCH v2 8/8] hook-list.h: add a generated list of hooks, like config-list.h Ævar Arnfjörð Bjarmason
2021-09-27 16:48     ` Junio C Hamano
2021-09-27 18:00       ` René Scharfe
2021-09-27 20:23         ` Junio C Hamano
2021-09-27  9:30   ` [PATCH v2 0/8] Makefile: generate a hook-list.h, prep for config-based-hooks Phillip Wood
2021-09-27 10:38     ` Ævar Arnfjörð Bjarmason
2021-09-27 18:01       ` Phillip Wood

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=211115.86bl2lqbbt.gmgdl@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=emilyshaffer@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=l.s.r@web.de \
    --cc=mh@glandium.org \
    --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 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.