Re: [PATCH v2 0/6] Makefile: add {program,xdiff,test,git}-objs & objects targets

From: Jeff King <peff@peff.net>
Date: Feb 4, 2021, 07:06 UTC
Message-ID: <YBuc5iOCCHk4fPqs@coredump.intra.peff.net>
In-Reply-To: <xmqqft2edkfg.fsf@gitster.c.googlers.com>

On Tue, Feb 02, 2021 at 05:11:47PM -0800, Junio C Hamano wrote:

Show 25 quoted lines

> Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:
> 
> > A re-send of v1
> > (https://lore.kernel.org/git/20210128182310.26787-1-avarab@gmail.com)
> > + a trivial whitespace fix in 2/6.
> 
> I'll reproduce what it said for those who are reading from
> sidelines:
> 
>     As noted there I can just run "make git", which I'd somehow managed to
>     miss. So that complexity isn't needed.
> 
>     But Jeff King suggested a hack to just get you to the point of
>     git.o. I don't need that right now, but that seems sensible, so I
>     implemented it.
> 
>     At the start of this series I've got a patch to make "all" stop
>     redundantly depending on "FUZZ_OBJS", which also helps with such
>     "rebase -i --exec=..." use-cases.
> 
> I do not see much point in the goal, not quite.  You can do "make
> git.o" and "make git" and you do not have to build unrelated things.
> 
> Isn't that already happening at the tip of 'master' (or 'maint'), or
> am I missing something?

I guess I can take some of the blame since my name came up in the justification above. ;)

The original use case I presented was quickly sifting through a series of commits for "oops, which one broke the compile". And so I wanted something like "make objects" to test each one as quickly as possible. And while that's a useful (if ugly) goal, I think it was misguided:

  - I usually know where the breakage is (after all, I saw it in the end
    state). So "make foo.o" would be faster still! (it would be even
    more so if the Makefile didn't insist on running GIT-VERSION-GEN,
    but that's another story).

  - the link step in "make git" is not that much slower than building
    the objects. And it catches more breakages (like undefined
    functions). It doesn't catch problems in non-builtins, though.

  - really, "make all" is not even that much slower than "make git".
    It's a 200ms difference on my machine (wall-clock; "make -j16" helps
    a lot here). That adds up if you are testing 100 commits, but it
    probably isn't worth thinking too hard about.

I do like the cleanups earlier in the series (I have mixed feelings on the first patch, though; see my comments there).

-Peff