Re: [PATCH v2 1/1] Makefile: use `git ls-files` to list header files, if possible
- Date: Mon, 4 Mar 2019 21:01:54 +0000
- From: Ramsay Jones <ramsay@xxxxxxxxxxxxxxxxxxxx>
- Subject: Re: [PATCH v2 1/1] Makefile: use `git ls-files` to list header files, if possible
On 04/03/2019 20:38, Ramsay Jones wrote:
> On 04/03/2019 13:47, Johannes Schindelin via GitGitGadget wrote:
>> From: Johannes Schindelin <johannes.schindelin@xxxxxx>
>> In d85b0dff72 (Makefile: use `find` to determine static header
>> dependencies, 2014-08-25), we switched from a static list of header
>> files to a dynamically-generated one, asking `find` to enumerate them.
>> Back in those days, we did not use `$(LIB_H)` by default, and many a
>> `make` implementation seems smart enough not to run that `find` command
>> in that case, so it was deemed okay to run `find` for special targets
>> requiring this macro.
>> However, as of ebb7baf02f (Makefile: add a hdr-check target,
>> 2018-09-19), $(LIB_H) is part of a global rule and therefore must be
>> expanded. Meaning: this `find` command has to be run upon every
>> `make` invocation. In the presence of many a worktree, this can tax the
>> developers' patience quite a bit.
>> Even in the absence of worktrees or other untracked files and
>> directories, the cost of I/O to generate that list of header files is
>> simply a lot larger than a simple `git ls-files` call.
>> Therefore, just like in 335339758c (Makefile: ask "ls-files" to list
>> source files if available, 2011-10-18), we now prefer to use `git
>> ls-files` to enumerate the header files to enumerating them via `find`,
>> falling back to the latter if the former failed (which would be the case
>> e.g. in a worktree that was extracted from a source .tar file rather
>> 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, but that is
> Heh, just to be _unnecessarily_ picky, but this is not always true.
> The 'command-list.h' header is _sometimes_ not included in the LIB_H
> variable - it simply depends on whether it has been generated by the
> time the $(FIND) is called.
> Obviously, not worth a re-roll. Otherwise, this LGTM.
Ahem! Obviously, I didn't read the commit message closely enough!
However, _before_ this change, then 'command-list.h' was sometimes
not included in $(LIB_H) ...
Sorry for the noise!