On 05/03/2019 23:07, Jeff King wrote: > On Tue, Mar 05, 2019 at 02:50:11PM +0900, Junio C Hamano wrote: > >> Jeff King <peff@xxxxxxxx> writes: >> >>> This makes sense to me, though as you noted elsewhere, it doesn't fix >>> the gcrypt problem, since that file unconditionally wants to look at the >>> system gcrypt.h (and we control at the Makefile level whether we >>> actually look at sha256/gcrypt.h). >> >> Hmm, is that because the header check target does not know which *.h >> files we ship are actually used in a particular build? > > Yes, exactly. > >> After a normal build, with dynamic dependency checking on, we would >> have sufficient information to figure it out. Would that help? > > Yeah, that's what I was hinting at earlier in the thread. Here it is > sketched out to an actual working patch. The sub-make bits could > actually be a shell script instead of a Makefile; the only point in > using make is to use the parent "-j" for parallelism. sigh. :( I wish my patch removing this target had been picked up now! Earlier this evening I spent an hour or so writing an email which tried to discourage spending any time on this, because of the potential for this to be a huge time-suck. An unrewarding one at that! :-D The email was actually prompted by someone mentioning 'dynamic compiler dependencies', because that's how it always starts ... I deleted that email (it's not in my drafts folder anyway) because, in the end, it is not up to me to say how people should spend their time. So I won't! :-D ATB, Ramsay Jones
