Bruno Haible writes:
> Sam James wrote:
>> > I see... you are building a cache that will become invalid when either
>> > - the bootstrap.conf changes, or
>> > - there is a change in gnulib in one of the request modules (in the
>> > module description or in code).
>>
>> We could also
Sam James wrote:
> > I see... you are building a cache that will become invalid when either
> > - the bootstrap.conf changes, or
> > - there is a change in gnulib in one of the request modules (in the
> > module description or in code).
>
> We could also probably cache based on (g)libc
Bruno Haible writes:
> Simon Josefsson wrote:
>> I now
>> remember that something like this was discussed before:
>>
>> https://git.savannah.gnu.org/cgit/libidn.git/commit/?id=9ae53e866a6fafa56db26d184ccae9c39dae7446
>> https://lists.gnu.org/archive/html/bug-gnulib/2021-05/msg00077.html
>
> I
Simon Josefsson wrote:
> I now
> remember that something like this was discussed before:
>
> https://git.savannah.gnu.org/cgit/libidn.git/commit/?id=9ae53e866a6fafa56db26d184ccae9c39dae7446
> https://lists.gnu.org/archive/html/bug-gnulib/2021-05/msg00077.html
I see... you are building a cache
Bruno Haible writes:
> Simon Josefsson wrote:
>> is it possible to design a reliable
>> caching mechanism? Something similar to CONFIG_SITE for autoconf?
>
> CONFIG_SITE is not reliable; that's the problem with it...
>
>> I find that ./gnulib-tool takes a long time and 95% of the time I use
>>
Simon Josefsson wrote:
> is it possible to design a reliable
> caching mechanism? Something similar to CONFIG_SITE for autoconf?
CONFIG_SITE is not reliable; that's the problem with it...
> I find that ./gnulib-tool takes a long time and 95% of the time I use
> it, it ended up doing exactly the
