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

Ævar Arnfjörð Bjarmason  [off-list ref] 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?


$ make V=1 git.o
GIT_VERSION = 2.30.0
    * new build flags
    * new prefix flags
cc -o git.o -c -MF ./.depend/git.o.d -MQ git.o -MMD -MP  -Werror -Wall -Wdeclaration-after-statement -Wformat-security -Wold-style-definition -Woverflow -Wpointer-arith -Wstrict-prototypes -Wunused -Wvla -fno-common -Wextra -Wmissing-prototypes -Wno-empty-body -Wno-missing-field-initializers -Wno-sign-compare -Wno-unused-parameter  -g -O2 -Wall -I. -DHAVE_SYSINFO -DGIT_HOST_CPU="\"x86_64\"" -DHAVE_ALLOCA_H  -DUSE_CURL_FOR_IMAP_SEND -DSHA1_DC -DSHA1DC_NO_STANDARD_INCLUDES -DSHA1DC_INIT_SAFE_HASH_DEFAULT=0 -DSHA1DC_CUSTOM_INCLUDE_SHA1_C="\"cache.h\"" -DSHA1DC_CUSTOM_INCLUDE_UBC_CHECK_C="\"git-compat-util.h\"" -DSHA256_BLK  -DHAVE_PATHS_H -DHAVE_DEV_TTY -DHAVE_CLOCK_GETTIME -DHAVE_CLOCK_MONOTONIC -DHAVE_GETDELIM '-DPROCFS_EXECUTABLE_PATH="/proc/self/exe"' -DFREAD_READS_DIRECTORIES -DNO_STRLCPY -DSHELL_PATH='"/bin/sh"' -DPAGER_ENV='"LESS=FRX LV=-c"' '-DGIT_HTML_PATH="share/doc/git-doc"' '-DGIT_MAN_PATH="share/man"' '-DGIT_INFO_PATH="share/info"' git.c

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

Ævar Arnfjörð Bjarmason  [off-list ref] writes:

quoted

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