gnulib-tool.py: Emit libtests in testdirs generated Makefile.am.

I just pushed the two patches I sent previously. Patch 0001 is the fix for missing libtests in testdirs. Patch 0002 is the type hints for classes. Hopefully no other bug reports for gnulib-tool.py since the info-gnu announcement other than the one I just patched is a good sign? :) CollinFrom

Re: warnings in unit tests

Hi Bruno, On 4/29/24 3:12 PM, Bruno Haible wrote: > Note that different warning policies may contradict each other. For example, > some people want to see a warning for > > int *table = malloc (n * sizeof (int)); > > because it has an implicit conversion / "lacks a cast". While other people

Re: warnings in unit tests

Hi Collin, > > For test cases this is more a judgment call, but I prefer doing either > > the above or adjusting the warning flags, to ignoring warnings, as the > > other warnings can be useful at time. > > Yeah, I could see these warnings making it hard to see ones that > actually matter. Lets

Re: Fetch from existing gnulib Git repository if needed

Hi Bruno, Bruno Haible wrote: > Markus Mützel wrote: > > However, it looks like $GNULIB_SRCDIR is empty for us. So, the change > > doesn't seem to make a difference. Executing bootstrap after a revision > > bump still fails if the bootstrap script was already run before. > > Oh, there were two

Unknown type name 'wint_t' when targeting Cygwin

Dear gnulib maintainers, We recently updated gnulib to a newer revision in GNU Octave (currently 92d80242ad1344b5364ca9bd1d995d68c3a73ef7). Since then we are seeing compilation errors like the following when targeting Cygwin: In file included from /usr/include/sys/reent.h:16,

Re: Unknown type name 'wint_t' when targeting Cygwin

Hi Bruno, On 4/29/24 12:02 AM, Bruno Haible wrote: > Which Cygwin version, please? > > Also, what is the gcc command line of this particular compilation unit? > (`make V=1`) While you wait for the answer to this, I noticed that Cygwin does things similar to glibc. In sys/_types.h [1]:

Re: Unknown type name 'wint_t' when targeting Cygwin

Hi Markus, Markus Mützel wrote: > We recently updated gnulib to a newer revision in GNU Octave (currently > 92d80242ad1344b5364ca9bd1d995d68c3a73ef7). > > Since then we are seeing compilation errors like the following when targeting > Cygwin: Which Cygwin version, please? Also, what is the

Re: Unknown type name 'wint_t' when targeting Cygwin

Hi Bruno, Bruno Haible wrote > Which Cygwin version, please? That error occurred, e.g., in a CI run https://github.com/gnu-octave/octave/actions/runs/8873331621/job/24358996111 The log of that run contains the following line: Starting cygwin install, version 2.932 Is that the Cygwin version?

Re: [PATCH] gnulib: close file handler before exiting

Hi, > diff --git a/lib/gen-uni-tables.c b/lib/gen-uni-tables.c > index 3ebcd83..94c687f 100644 > --- a/lib/gen-uni-tables.c > +++ b/lib/gen-uni-tables.c > @@ -242,6 +242,8 @@ fill_attributes (const char *unicodedata_filename) > { >fprintf (stderr, "missing end range

gnulib-tool.py: Add type hints to classes.

This patch adds type hints to the Python classes. Same as previously done in GLFileTable that I wrote. The only new thing introduced is the syntax for class variables, so this line in a class definition: section_label_pattern = re.compile(...) becomes this: section_label_pattern:

[PATCH] gnulib: close file handler before exiting

--- lib/gen-uni-tables.c | 4 1 file changed, 4 insertions(+) diff --git a/lib/gen-uni-tables.c b/lib/gen-uni-tables.c index 3ebcd83..94c687f 100644 --- a/lib/gen-uni-tables.c +++ b/lib/gen-uni-tables.c @@ -242,6 +242,8 @@ fill_attributes (const char *unicodedata_filename) {

Re: doc: Update macro list in gnulib-cache.m4 documentation.

Collin Funk wrote: > I've applied the attached patch updating the macro list in the > gnulib-cache.m4 documentation. Thanks! Appreciated.

Re: gnulib-tool: Use the Python implementation by default

Hi folks, sorry for the long silence! I've been tracking your progress for a while, even though sporadically and remaining silent. I'd like to say "thank you" to Bruno and Collin, who made it this far and never surrendered. :-) Truth to be told, the code I implemented leaves much to be desired,

Re: gnulib-tool: Use the Python implementation by default

Hi Dmitry, The biggest "thank you" is yours, since you did the majority of the work (my estimations: you 4 months, Collin 2 months, me 1 month). OO is hard. I was and am still impressed about how your dissection of the code into classes (GLConfig, GLModule, GLModuleSystem, etc.) stood the test

Re: gnulib-tool.py: Add type hints to classes.

Hi Collin, > This patch adds type hints to the Python classes. Looks good. Thanks! > Same as previously done in GLFileTable that I wrote. The only new > thing introduced is the syntax for class variables, so this line in a > class definition: > > section_label_pattern = re.compile(...) >

Re: gnulib-tool: Use the Python implementation by default

Hi Dmitry, On 4/29/24 11:57 AM, Dmitry Selyutin wrote: > I've been tracking your progress for a while, even though sporadically and > remaining silent. I'd like to say "thank you" to Bruno and Collin, who made > it this far and never surrendered. :-) Thank you for the kind words! I'm glad you