gnulib-tool.py: Follow gnulib-tool changes, part 28.

Hi Bruno, I've attached two patches. The first one fixes an item in the gnulib-tool.py.TODO file. Previously the "Generated by gnulib-tool" comment at the top of the Makefile would be on one line. This splits it into multiple lines so that it can be used with git send-email and versions of AWK wit

Re: [PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 27.

On 2/23/24 3:51 PM, Bruno Haible wrote: > I.e. you meant to write > mode != None > not > modules != None > ? Oops. I'm not sure how I missed this in your original email as well... You are correct. It should be "mode != None". I should have a patch ready in a bit to fix another item in the gnul

Re: unictype/category-none tests: Fix a link error on MSVC

Simon Josefsson wrote in : > > The reason is that _UC_CATEGORY_NONE is not a public API of the shared > > library > > and therefore not exported. The simplest fix is to disable the test. > > Thanks -- although isn't that also a

Re: gperf dependency not documented

Gavin Smith wrote: > The DEPENDENCIES file in gnulib states a module that depends on the gperf > program: > > * GNU gperf 3.0.1 or newer. > + 3.0.1 or newer is mandatory, but 3.1 or newer is recommended. > Needed if you use the 'iconv_open' module. > > However, it is not the only module tha

Re: [PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 27.

Hi Collin, > > * gnulib-tool.py line 610: > > +if modules != None and "tests" in mode and gnu_make: > > ^^^ > > What is the rationale for this condition? It is not present in the > > original. Can > > it be removed? > > I added this condition in an attempt to mirror c

Re: [PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 27.

Hey Bruno, thanks for the feedback. On 2/23/24 5:08 AM, Bruno Haible wrote: > Just three small nits that you might want to revisit: > > * gnulib-tool.py line 610: > +if modules != None and "tests" in mode and gnu_make: > ^^^ > What is the rationale for this condition?

Re: u8_strconv_to_locale() misbehaves on OSX (Travis CI runner)

Tim Ruehsen wrote on 2018-02-08 in : > my direct call to locale_charset() is from gnulib. > > So my build correctly says UTF-8, but the homwbrew libunistring has > been built on some unknown (OSX ?) system with their own version

unictype/mirror: Update to Unicode 15.1.0

The data for the Unicode character mirroring was not up-to-date, because the data table was fixed in the code. But new mirroring pairs were added in Unicode 5.0.0 (10), 5.1.0 (5), 6.1.0 (1), 11.1.0 (28), 14.0.0 (4). This patch fixes it. 2024-02-23 Bruno Haible unictype/mirror: Update

gen-uni-tables: Keep line number better up-to-date

gen-uni-tables could, while reading EastAsianWidth.txt or LineBreak.txt, output a diagnostic with a wrong line number. The cause is that 'lineno' was not correctly kept up-to-date while reading a blank line. This patch fixes it. 2024-02-23 Bruno Haible gen-uni-tables: Keep line numbe

Re: [PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 27.

Hello Collin, Collin Funk wrote: > Hello, here is a patch implementing the --gnu-make option for > gnulib-tool.py. Thanks! Applied. This was already a major piece of work. > All of these > commits were grouped together and were similar so I felt like it > didn't make too much sense to handle the

Re: printf with %n directives

> 2024-02-21 Bruno Haible > > *printf-posix: Disable support for the 'n' directive by default. This produces 24 test failures in libunistring. Fixed as follows: 2024-02-23 Bruno Haible unistdio/*printf tests: Update expected test results regarding %n. * tests/unistd