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 pr
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 ver
On 2/19/24 1:36 PM, Bruno Haible wrote:
> You don't need to go to the './configure' and 'make' stages at this point.
> Just ensuring that the outputs of gnulib-tool and gnulib-tool.py are the
> same will sufficiently guide you.
Ah, I see. Thanks for this and the rest of the advice.
Collin
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 tha
On 2024-02-19 13:24, Bruno Haible wrote:
The larger part of the problem is not with Gnulib, but with the > 100
packages that use Gnulib.
Oh, I wasn't proposing that we use the simpler style in all apps, just
Gnulib.
It's not that big a deal, so let's just leave things be for now. (But if
we
Collin Funk wrote:
> > 65% of the .py code has been verified to be in sync with the bash code;
> > 35% still to go. And then, the changes from the gnulib-tool.py.TODO list
>
> I see. I had it open and compared some of it to the shell script and it
> wasn't too hard to follow. Maybe I could help ha
Paul Eggert wrote:
> > writing #include <...> everywhere has
> > very little benefit.
>
> There is a benefit: it's simpler and would avoid future problems like
> the one just fixed.
There is also a drawback: Remember why we took the habit of putting all
#include
before all
#include "applica
On 2024-02-19 03:03, Bruno Haible wrote:
writing #include <...> everywhere has
very little benefit.
There is a benefit: it's simpler and would avoid future problems like
the one just fixed.
Currently we have more-complicated guideline, which is that one should
use #include <...> for include
On Mon, Feb 19, 2024 at 12:45 AM Simon Josefsson wrote:
> Bruno Haible writes:
> > --- a/top/maint.mk
> > +++ b/top/maint.mk
> > @@ -503,6 +503,7 @@ sc_prohibit_have_config_h:
> > # Nearly all .c files must include . However, we also permit
> > this
> > # via inclusion of a package-specific h
Bruno Haible writes:
> The status: It's about 2/3 complete. 4 months of work have gone into it,
> and 2 months of work still remaining. (That's my estimation, based on
> two weeks of work that I put in, in 2022.)
> 65% of the .py code has been verified to be in sync with the bash code;
> 35% still
On Mon, Feb 19, 2024 at 10:11 AM Collin Funk wrote:
> Jim Meyering writes:
> > Thank you both. I've just pushed an improvement.
> > The new version runs grep only once rather than many times, and seems
> > simpler.
>
> Thanks. This one seems much better. It also returns 1 if an invalid
> quoted
Jim Meyering writes:
> Thank you both. I've just pushed an improvement.
> The new version runs grep only once rather than many times, and seems simpler.
Thanks. This one seems much better. It also returns 1 if an invalid
quoted header is found which I forgot to do. This Makefile would
probably be
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
>> i
Paul Eggert wrote:
> On 2024-02-18 04:19, Bruno Haible wrote:
> > +When including including specific header files, you need to use the
> > +@samp{#include <...>} syntax, not the @samp{#include "..."} syntax.
>
> Why does Gnulib source code ever use the #include "..." syntax?
Because that's the wa
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
Bruno Haible writes:
>> What is the status of the Python gnulib tool? I'm not sure how far
>> behind it is compared to the shell script but it seems like it would
>> be much faster. I would say more maintainable but I might just be bad
>> at writing shell scripts. :)
>
> Yes, it's the hope that i
Bruno Haible writes:
> --- a/top/maint.mk
> +++ b/top/maint.mk
> @@ -503,6 +503,7 @@ sc_prohibit_have_config_h:
> # Nearly all .c files must include . However, we also permit this
> # via inclusion of a package-specific header, if cfg.mk specified one.
> # config_h_header must be suitable for
18 matches
Mail list logo
