From: Ramsay Jones <ramsay@ramsayjones.plus.com>
To: Jeff King <peff@peff.net>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH 1/1] Makefile: use `git ls-files` to list header files, if possible
Date: Sun, 3 Mar 2019 21:30:17 +0000 [thread overview]
Message-ID: <8e4b7966-7a3e-a081-bfc1-9e60303b8eab@ramsayjones.plus.com> (raw)
In-Reply-To: <20190303171951.GD23811@sigill.intra.peff.net>
On 03/03/2019 17:19, Jeff King wrote:
> On Sat, Mar 02, 2019 at 09:05:24PM +0100, Johannes Schindelin wrote:
>
>>> That seems reasonable (regardless of whether it is in a script or in the
>>> Makefile). Another option is to use -maxdepth, but that involves
>>> guessing how deep people might actually put header files.
>>
>> It would also fail to work when somebody clones an unrelated repository
>> that contains header files in the top-level directory into the Git
>> worktree. I know somebody like that: me.
>
> Good point.
[Sorry for the late reply - I have been AWOL this weekend and
I am only just catching up with email! :-D ]
So, tl;dr: soon, I will be submitting a patch to remove the
'hdr-check' target completely, for now anyway.
> By the way, "make hdr-check" already fails for me on master, as I do not have
> libgcrypt installed, and it unconditionally checks sha256/gcrypt.h.
Yep, for me too. There is a similar problem if you build with
NO_CURL and don't have the 'curl/curl.h' header file, etc ...
The first version of the 'hdr-check' target re-introduced a static
list of header files, but I didn't think people would appreciate
having to maintain the list manually, so I gave up on that!
The next version was essentially the same patch that started this
thread from Johannes (ie. the 'git ls-files' patch), given that
the 'tags' targets had found it necessary. However, when I did some
'informal' timing tests (ie 5x 'time make ...' and average), this
did not make any noticeable difference for me (_even_ on cygwin!). ;-)
Of course, I had already made the mistake of trying to re-use
something that was 'handy' (ie. LIB_H) and already there.
However, LIB_H wasn't quite what I wanted - I needed a sub-set
of it.
So, I already have a 'hdr-check-fixup' branch (I think I have
already mentioned it), in which the first commit looks like:
diff --git a/Makefile b/Makefile
index c5240942f2..3401d1b9fb 100644
--- a/Makefile
+++ b/Makefile
@@ -2735,9 +2735,10 @@ $(SP_OBJ): %.sp: %.c GIT-CFLAGS FORCE
.PHONY: sparse $(SP_OBJ)
sparse: $(SP_OBJ)
+HC_HDRS := $(wildcard *.h negotiator/*.h block-sha1/*.h ppc/*.h ewah/*.h \
+ sha1dc/*.h refs/*.h vcs-svn/*.h)
GEN_HDRS := command-list.h unicode-width.h
-EXCEPT_HDRS := $(GEN_HDRS) compat% xdiff%
-CHK_HDRS = $(filter-out $(EXCEPT_HDRS),$(patsubst ./%,%,$(LIB_H)))
+CHK_HDRS = $(filter-out $(GEN_HDRS),$(HC_HDRS))
HCO = $(patsubst %.h,%.hco,$(CHK_HDRS))
$(HCO): %.hco: %.h FORCE
... which drops the use of LIB_H entirely.
Now, I have timed this and, for me, it no faster ... (I suspect
that it would be faster for Johannes, but it would still cause
a problem if you have 'top-level header files from some other
repo ...').
So, if we really need to solve the problem, allowing for some
unrelated headers in your worktree, then we can only use a
static list, or a 'git ls-files' approach.
Anyway, for now, since I seem to be the only person using this
target, I think we should just remove it while I think again.
(I can put it in my config.mak, so there will be no loss for me).
ATB,
Ramsay Jones
next prev parent reply other threads:[~2019-03-03 21:30 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-01 19:57 [PATCH 0/1] Avoid calling find in the Makefile, if possible Johannes Schindelin via GitGitGadget
2019-03-01 19:57 ` [PATCH 1/1] Makefile: use `git ls-files` to list header files, " Johannes Schindelin via GitGitGadget
2019-03-01 21:36 ` Jeff King
2019-03-01 21:54 ` Jeff King
2019-03-01 22:01 ` Jeff King
2019-03-02 19:54 ` Johannes Schindelin
2019-03-03 17:08 ` Jeff King
2019-03-02 19:57 ` Johannes Schindelin
2019-03-03 17:11 ` Jeff King
2019-03-02 20:05 ` Johannes Schindelin
2019-03-03 17:19 ` Jeff King
2019-03-03 21:30 ` Ramsay Jones [this message]
2019-03-04 12:38 ` Johannes Schindelin
2019-03-04 20:31 ` Ramsay Jones
2019-03-04 21:37 ` Jeff King
2019-03-04 11:08 ` Johannes Schindelin
2019-03-04 21:41 ` Jeff King
2019-03-05 5:50 ` Junio C Hamano
2019-03-05 15:28 ` Johannes Schindelin
2019-03-05 22:26 ` Junio C Hamano
2019-03-05 23:07 ` Jeff King
2019-03-06 0:23 ` Ramsay Jones
2019-03-06 4:40 ` Jeff King
2019-03-06 5:28 ` Junio C Hamano
2019-03-06 19:05 ` [PATCH] compat/bswap: add include header guards Jeff King
2019-03-06 22:42 ` Junio C Hamano
2019-03-04 13:47 ` [PATCH v2 0/1] Avoid calling find in the Makefile, if possible Johannes Schindelin via GitGitGadget
2019-03-04 13:47 ` [PATCH v2 1/1] Makefile: use `git ls-files` to list header files, " Johannes Schindelin via GitGitGadget
2019-03-04 20:38 ` Ramsay Jones
2019-03-04 21:01 ` Ramsay Jones
2019-03-04 21:43 ` Jeff King
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8e4b7966-7a3e-a081-bfc1-9e60303b8eab@ramsayjones.plus.com \
--to=ramsay@ramsayjones.plus.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).