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

Here is two patches. The first fixes on item in gnulib-tool.py.TODO. I thought I remembered seeing a good test case for this on the mailing list but the archives seem to be down at the moment. The second fixes this diff in gnulib-cache.m4 I found when testing: diff --git a/test-python/m4/gnulib-c

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

Collin Funk wrote: > I've attached a patch that uses the condition: > > if dictionary['var'] == 'SUBDIRS' and dictionary['dotfirst']: > > which should match the original commit. Yes, this looks good. Applied; thanks! Bruno

Re: doc/Copyright/request-assign.future is not up to date?

Karl Berry wrote: > Gnulib takes its version from fencepost:/gd/gnuorg/Copyright, which is > where the maintainers document states the official versions, of that and > other such files, are found. Yes. > Can you please ask ass...@gnu.org (I guess) to update it? We have already raised the topic w

Re: doc/Copyright/request-assign.future is not up to date?

Stefan Monnier mentioned that the FSF copyright form has been recently updated adding the following clause: [Additional people we should notify about the progress of the assignment.] Gnulib takes its version from fencepost:/gd/gnuorg/Copyright, which is where the maintainers docu

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

Hi Bruno, On 3/5/24 3:08 PM, Bruno Haible wrote: > Oops, these comments of mine apply to part 41, not part 40! No worries. I should have numbered the patches 0001, 0002, 0003 to make your life easier. :) >> Thanks, but there's a difference here: >> In gnulib-tool the condition was >> >>

Re: Could `gnulib-tool` check for gjoin?

On 3/5/24 10:06 AM, Bruno Haible wrote: > Reuben Thomas wrote: >> macOS users are typically not developing the software but helping me port >> it to macOS, hence building from git > > I see. > >> On >> macOS, as you are aware, out-of-date coreutils are installed on the system. >> The most common

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

Collin Funk wrote: > Here is a simple patch that fixes the conditionals when using > --gnu-make. Thanks, applied. Bruno

Re: [PATCH 1/2] gnulib-tool.py: Follow gnulib-tool changes, part 41.

Hi Collin, > After that we get the following diff: This is much nicer indeed. I have applied the 0002-* patch. Bruno

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

Oops, these comments of mine apply to part 41, not part 40! > Thanks, but there's a difference here: > In gnulib-tool the condition was > > if test "${var}" = SUBDIRS && test -n "$dotfirst"; then > > whereas in your patch, in pygnulib/GLEmiter.py lines 804 and 1108, I see > >

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

Collin Funk wrote: > While working on another item in the TODO, I think I found a mistake > but it is hard for me to tell from diff'ing the output at the moment. > > I think the two lines I've linked are referring to the same thing. > ... > Shouldn't the Python one be using 'self.emitter.tests_Mak

Re: Could `gnulib-tool` check for gjoin?

On Tue, 5 Mar 2024 at 22:23, Reuben Thomas wrote: > > I'm asking to have a workaround for each program that gnulib uses in one > place (in gnulib) rather than have every user of every package who wants to > build from git on macOS have to add the PATH workaround, which is the sort > of thing I re

Re: Could `gnulib-tool` check for gjoin?

On Tue, 5 Mar 2024 at 21:47, Bruno Haible wrote: > > The programs are also in a libexec/gnubin/ directory, as symlinks, without > the 'g' prefix. See [1] line 80 and [2] line 39. > Indeed. So, it seems to me that it is simpler to ask the users to put this > libexec/gnubin/ directory in front of

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

Collin Funk wrote: > Here is a simple patch that fixes the conditionals when using > --gnu-make. It should be pretty easy to test with the Emacs script if > you would like to double check. Thanks, but there's a difference here: In gnulib-tool the condition was if test "${var}" = SUBDIRS &

Re: Could `gnulib-tool` check for gjoin?

Reuben Thomas wrote: > > When people install the coreutils through Homebrew, which prefix do the > > programs have by default? Is it "g", or is it none? > > There seem to be two different ways: either with no prefix (e.g. m4), or > with `g` prefix (e.g. coreutils) Indeed, coreutils ([1] line 61)

Re: doc/Copyright/request-assign.future is not up to date?

On 2024-03-05 09:02, Bruno Haible wrote: Ihor Radchenko wrote: ... https://lists.gnu.org/archive/html/emacs-devel/2024-03/msg00101.html Stefan Monnier mentioned that the FSF copyright form has been recently updated adding the following clause: [Additional people we should notify about the

Re: Could `gnulib-tool` check for gjoin?

On Tue, 5 Mar 2024 at 19:06, Bruno Haible wrote: > > When people install the coreutils through Homebrew, which prefix do the > programs have by default? Is it "g", or is it none? > There seem to be two different ways: either with no prefix (e.g. m4), or with `g` prefix (e.g. coreutils); in both

Re: [PATCH] doc: remove FreeBSD as missing platform for fopencookie

Michael Ford wrote: > The following patch ammends the documentation for fopencookie, given > it is now available on FreeBSD (since the 11.x release). > > From d2d7a0b8bf4a46e8761b6336a686df1ad235946e Mon Sep 17 00:00:00 2001 > From: fanquake > Date: Tue, 5 Mar 2024 14:57:30 + > Subject: [PATC

Re: Could `gnulib-tool` check for gjoin?

Reuben Thomas wrote: > macOS users are typically not developing the software but helping me port > it to macOS, hence building from git I see. > On > macOS, as you are aware, out-of-date coreutils are installed on the system. > The most common way to get up-to-date coreutils, I understand, is to

Re: Could `gnulib-tool` check for gjoin?

On Tue, 5 Mar 2024 at 18:51, Bruno Haible wrote: > > The habit of installing GNU coreutils with --program-prefix=g was common > on OSes like Solaris and *BSD, when people wanted to do serious development > on these platforms. But nowadays, why would anyone choose to do their > development on Sola

Re: --create-testdir speed

Tim Rice wrote: > > +@noindent > > +(You can't do this will all of Gnulib at once: @code{gnulib-tool} would run > Thanks; fixed: 2024-03-05 Bruno Haible doc: Fix a typo. Reported by Tim Rice in

Re: Could `gnulib-tool` check for gjoin?

Hi Reuben, > Now that gnulib checks that `join` is working, could it also try `gjoin` as > a fallback, in the same way that other tools are searched for with a `g` > prefix, e.g. `glibtoolize` and `gxargs`? It could. But the gnulib-tool user (a developer) can just as well create a symlink join ->

Could `gnulib-tool` check for gjoin?

Now that gnulib checks that `join` is working, could it also try `gjoin` as a fallback, in the same way that other tools are searched for with a `g` prefix, e.g. `glibtoolize` and `gxargs`? -- https://rrt.sc3d.org

Re: doc/Copyright/request-assign.future is not up to date?

Ihor Radchenko wrote: > This message is a follow up from emacs-devel discussion > https://lists.gnu.org/archive/html/emacs-devel/2024-03/msg00101.html > > Stefan Monnier mentioned that the FSF copyright form has been recently > updated adding the following clause: > > [Additional people we sh

c-strtof, c-strtod, c-strtold: Make multithread-safe

This patch makes the c_strtof, c_strtod, c_strtold functions multithread-safe on all platforms. The multithread-safety unit tests, that previously failed on - Solaris 11.3 - mingw, MSVC 14 - FreeBSD 5.2.1 now pass on these platforms. 2024-03-05 Bruno Haible c-strtof, c-strtod, c

[PATCH] doc: remove FreeBSD as missing platform for fopencookie

The following patch ammends the documentation for fopencookie, given it is now available on FreeBSD (since the 11.x release). >From d2d7a0b8bf4a46e8761b6336a686df1ad235946e Mon Sep 17 00:00:00 2001 From: fanquake Date: Tue, 5 Mar 2024 14:57:30 + Subject: [PATCH] doc: remove FreeBSD as missing

doc/Copyright/request-assign.future is not up to date?

This message is a follow up from emacs-devel discussion https://lists.gnu.org/archive/html/emacs-devel/2024-03/msg00101.html Stefan Monnier mentioned that the FSF copyright form has been recently updated adding the following clause: [Additional people we should notify about the progress of th

c-strto{f,d,ld}: Add multithread-safety tests

These three patches add multithread-safety tests for the functions c_strtof, c_strtod, c_strtold. And, sure enough, these tests fail, due to the use of setlocale(), on - Solaris 11.3 - mingw, MSVC 14 - FreeBSD 5.2.1 They probably also fail on AIX (on systems which have a French locale install

locale-*.m4: Update comments

The locale names in Solaris 10 and Solaris 7 follow the same conventions. 2024-03-05 Bruno Haible locale-*.m4: Update comments. * m4/locale-ar.m4: Update comments for Solaris 10. * m4/locale-fr.m4: Likewise. * m4/locale-ja.m4: Likewise. * m4/locale-tr.m

[PATCH 1/2] gnulib-tool.py: Follow gnulib-tool changes, part 41.

On 3/4/24 9:44 PM, Collin Funk wrote: > I think the two lines I've linked are referring to the same thing. The > 'inctest' was changed to 'gentests' in commit > dc135c4fd14cdc219d316c61f344e64090cb33fd which is what I was working > on. Shouldn't the Python one be using 'self.emitter.tests_Makefile_