Skip to content

Avoid calling find in the Makefile, if possible

Johannes Schindelin via GitGitGadget git 2 versions – In review

Get series with b4
b4 am [email protected]

Versions newest first · linked by author and title

  1. v2 Latest1 patch 3 repliesIn review
  2. v11 patch 22 repliesSuperseded

Changes in v2 from the cover letter

* Since LIB_H's lazy evaluation kicks in all the time anyway, changed the = to := to avoid evaluating it three times.
* Clarified in the commit message that the existing sites using $(LIB_H) are not affected by this change (or at least not affected as long as no untracked header files are included in .c files).

Patches in v2 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/1Makefile: use `git ls-files` to list header files, if possibleMakefile+3 -23 replies

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v2 yet.

Read the v2 thread

Cover letter [PATCH v2 0/1] Avoid calling find in the Makefile, if possible

I noticed this quite a bit of time ago, but did not get a chance to look into it in detail: all of a sudden, make started really slowly over here.

The culprit turned out to be a find call, which was in the Makefile for ages, so I was puzzled why it only caused problems recently.

After some digging, I found out that the hdr-check target is the culprit:
before it was introduced, $(LIB_H) did not need to be expanded, and as a consequence the find call was not executed. Once hdr-check made it into master, though, $(LIB_H) must be expanded to define that rule.

Since I have tons of worktrees as subdirectories of my principal Git clone, and since I also have a 3rdparty/ directory with tons of repositories I use for various testing/contributing purposes, this find is quite a little slow over here.

So here is my suggested fix. It is based on similar code we already had in the Makefile, obviously also intended to avoid an expensive find invocation.

Changes since v1:

* Since LIB_H's lazy evaluation kicks in all the time anyway, changed the = to := to avoid evaluating it three times.
* Clarified in the commit message that the existing sites using $(LIB_H) are not affected by this change (or at least not affected as long as no untracked header files are included in .c files).

Johannes Schindelin (1):
Makefile: use git ls-files to list header files, if possible

 Makefile | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

base-commit: c65a2884eae159bad540135479bc8afe20ff62d1
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-130%2Fdscho%2Favoid-find-in-makefile-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-130/dscho/avoid-find-in-makefile-v2
Pull-Request: https://github.com/gitgitgadget/git/pull/130

Range-diff vs v1:

1: 0b5529406b ! 1: cb253bd0cf Makefile: use git ls-files to list header files, if possible
@@ -29,7 +29,11 @@
than from a clone of Git's sources).

This has one notable consequence: we no longer include command-list.h
- in LIB_H, as it is a generated file, not a tracked one.
+ in LIB_H, as it is a generated file, not a tracked one, but that is
+ easily worked around. Of the three sites that use LIB_H, two
+ (LOCALIZED_C and CHK_HDRS) already handle generated headers
+ separately. In the third, the computed-dependency fallback, we can just
+ add in a reference to $(GENERATED_H).

Likewise, we no longer include not-yet-tracked header files in LIB_H.

@@ -46,7 +50,7 @@
GENERATED_H += command-list.h

-LIB_H = $(shell $(FIND) . \
-+LIB_H = $(shell git ls-files '*.h' ':!t/' ':!Documentation/' 2>/dev/null || \
++LIB_H := $(shell git ls-files '*.h' ':!t/' ':!Documentation/' 2>/dev/null || \
+ $(FIND) . \
-name .git -prune -o \
-name t -prune -o \

Signature · 1 line
gitgitgadget