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 <p...@peff.net> 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
