Re: [PATCH 1/1] Add optional targets for documentation l10n

From: Junio C Hamano <gitster@pobox.com>
To: "Jean-Noël AVILA" <jn.avila@free.fr>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 1/1] Add optional targets for documentation l10n
Date: Mon, 07 Jan 2019 11:29:43 -0800	[thread overview]
Message-ID: <xmqqh8ek8dw8.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: 220955359.FqXrlbFPp5@cayenne

Jean-Noël AVILA <jn.avila@free.fr> writes:

>> The idea is to use $(filter PATTERN..., TEXT) that removes words in
>> TEXT that do not match any of the words in PATTERN, and for normal
>> build, MAN_FILTER is set identical to TMP_MAN_TXT (which is the
>> original MAN_TXT), so there is no filtering happen, but in a build
>> that does tweak MAN_FILTER, MAN_TXT can become a subset of the
>> original MAN_TXT.
>> 
>> Am I on the right track?
>>
>
> Yes that's exactly the purpose of this trick. In fact, $(filter) in this 
> configuration is equivalent to an intersection of lists, so the order does not 
> change the end result.

That is only true if MAN_FILTER is literally a list of "I want
exactly these things", without any pattern.  Once a future caller
wants to say "We now have translations for pages from [a-m]*", it
becomes apparent again that the order is wrong.

And if the caller is supposed to have a literal list of pages, not a
pattern, then it may be sufficient to update our Makefile so that
the caller can override the literal list of pages we (incrementally)
compute with its own list without any filtering.

> Ah, I see. The filter from MAN{1,5,7}_TXT would ripple the same way as MAN_TXT, 
> just one level upstream.  The filtering at this level would no longer be 
> needed.

Yup.  I see you sent v2; let me read it.

Thanks.