Re: limits-h: Fix BOOL_MAX value

On 2/12/24 5:09 AM, Bruno Haible wrote: > BOOL_WIDTH = 1, BOOL_MAX = 1 > with CC="gcc -std=gnu2x", but > BOOL_WIDTH = 8, BOOL_MAX = 1 > with CC="clang -std=gnu2x" (for all clang version 14 ... 17). Same results with GCC 14 and Clang 19. > Apparently I had misinterpreted the meaning of BOOL_

[PATCH] math: Silence -Winclude-next-absolute-path warning.

thing. Thanks! CollinFrom 269dfab932a01cfbbb5382b8955f06d065eea149 Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Sat, 17 Feb 2024 00:19:17 -0800 Subject: [PATCH] math: Silence -Winclude-next-absolute-path warning. See commit f4fccf8efdd09d5e38f49f6ae1962797ce3e8e9c for more information. * lib/m

Re: [PATCH] math: Silence -Winclude-next-absolute-path warning.

On 2/17/24 2:51 AM, Bruno Haible wrote: > I also applied this patch, to complete > : Thanks, gettext warns a lot about that header. I'll submit a patch over there later today.

Re: syntax-check rule to silence -Winclude-next-absolute-path warning

315b3514181c1369da067516c1ec7c2a23a203 Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Sun, 18 Feb 2024 12:02:33 -0800 Subject: [PATCH] maint.mk: Add syntax-check rule to check for #include syntax. * top/maint.mk (sc_verify_absolute_include_headers): New rule to check for #includes that might

[PATCH] gnulib-tool.py: Fix function call on incorrect object.

iting shell scripts. :) CollinFrom 49adb8c6c480d42a2ad90f52fde10df9929506fb Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Sun, 18 Feb 2024 16:52:45 -0800 Subject: [PATCH] gnulib-tool.py: Fix function call on incorrect object. * pygnulib/GLImport.py: Call checkInclTestCategory on the GLCon

Re: syntax-check rule to silence -Winclude-next-absolute-path warning

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

Re: [PATCH] gnulib-tool.py: Fix function call on incorrect object.

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

Re: [PATCH] gnulib-tool.py: Fix function call on incorrect object.

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

Re: syntax-check rule to silence -Winclude-next-absolute-path warning

nto the Makefile... Sorry about that. I attached the fix. Collin From 1f526466d4a2c54ea227e438c12127fc305c2a43 Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Tue, 20 Feb 2024 12:16:40 -0800 Subject: [PATCH] maint.mk: Fix include header typo. top/maint.mk: Change arpa_inet.h to arpa/inet

Re: new modules for libunistring metadata

On 2/20/24 4:15 PM, Bruno Haible wrote: > It's better if this metadata is generated from gen-uni-tables.c. This > eliminates a manual step. These patches do it. Would it make sense to provide a macro to check if the current version is greater than or equal to a given version? Or should that just b

Re: new modules for libunistring metadata

On 2/20/24 6:10 PM, Bruno Haible wrote: > For my feeling, there's too little added value in such a macro. > > Remember the costs of documenting a function or macro: > - The user needs more time to read the documentation. > - The developer needs to code and document it. Fair enough. I assume t

[PATCH] gnulib-tool.py: Comment out undefined variable.

ork with the dummy module so I can start comparing the output while learning the code.From 6d94d65bfb0afc77c28b9c3a4633d156eb94906a Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Wed, 21 Feb 2024 03:25:37 -0800 Subject: [PATCH] gnulib-tool.py: Comment out undefined variable. * pygnulib/GLTestDir.py (G

Re: [PATCH] gnulib-tool.py: Comment out undefined variable.

b2ee9537298dd76d683ec9c4298f22c53f45f6f5 Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Wed, 21 Feb 2024 08:54:51 -0800 Subject: [PATCH] gnulib-tool.py: Fix undefined variable while emitting testdir. * pygnulib/GLTestDir.py (GLTestDir.execute): Fix undefined variable refrence caused by commit 0

[PATCH] gnulib-tool.py: Improve output of testdir Makefile.am.

-stringsFrom 159fec290bd19f20f98fce1de053cff2bc69d67d Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Wed, 21 Feb 2024 12:21:24 -0800 Subject: [PATCH] gnulib-tool.py: Improve output of testdir Makefile.am. * pygnulib/GLEmiter.py (GLEmiter.tests_Makefile_am): Add 'all-notice' rule as dependen

Re: [PATCH] gnulib-tool.py: Improve output of testdir Makefile.am.

On 2/21/24 4:10 PM, Bruno Haible wrote: > I'm a bit unhappy with this way of working. Your patches surely > go into the right direction, but I would prefer to receive them > 1) one by one, > 2) with the corresponding gnulib-tool.py.TODO entry removal. > Because if we don't keep track of which e

Re: [PATCH] gnulib-tool.py: Improve output of testdir Makefile.am.

ssage without a part number. I wasn't sure if you wanted to continue them/restart since all of them are your patches from ~2 years ago. Feel free to add one if you would like and I'll see it before submitting another. Thanks, CollinFrom f6051b9bb07b5474879f4f462984b8a1f02aa221 Mon Sep 17

Re: [PATCH] gnulib-tool.py: Improve output of testdir Makefile.am.

On 2/22/24 8:53 AM, Bruno Haible wrote: > I added the part number, since it gives us a certain feeling of how far we > have gotten along. Also, I copy&pasted the date+author line from > the ChangeLog; the 'git log' contains the same data with slightly different > formatting. Sounds good to me. I'l

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

0ad36681386e5878a841abcdc3e834629e9a958 Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Thu, 22 Feb 2024 11:27:42 -0800 Subject: [PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 26. Follow gnulib-tool change 2017-04-20 Bruno Haible verify tests: Fix spurious failure with parallel make.

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

ssed. Thanks, Collin [1] https://git.savannah.gnu.org/cgit/emacs.git/tree/admin/merge-gnulibFrom edf3dd7dc7f0d8c2b4bd77213554a236e23dca4e Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Thu, 22 Feb 2024 20:16:18 -0800 Subject: [PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 27. Follow gnuli

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: [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

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

on otherwise... I made sure to give you credit in the ChangeLog entry. Thanks, CollinFrom 52abea086e7c33723e255202a121d555a41b652d Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Fri, 23 Feb 2024 20:52:15 -0800 Subject: [PATCH 1/2] gnulib-tool.py: Follow gnulib-tool changes, part 28. Follow

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

Hi Bruno, Thanks for fixing the typo in the other email. I'll remember to use 'foo' instead of "foo". That is a personal habit of mine but I now realize that it goes against all of the existing code... On 2/24/24 3:42 PM, Bruno Haible wrote: > The sorted(...) instruction is not present in gnulib-

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

On 2/24/24 4:47 PM, Collin Funk wrote: > Anyways, upon further inspection not all of the gnulib-modules are > sorted in merge-gnulib. When "unlocked-io" was added to Emacs it was > placed after "update-copyright" [1]. I assume that they are sorted > somewhere bef

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

less likely to be broken by future changes. The changes involve using a set and sorted() to substitute `sort -u'. [1] https://git.savannah.gnu.org/cgit/gnulib.git/tree/gnulib-tool#n5085 [2] https://git.savannah.gnu.org/cgit/gnulib.git/tree/gnulib-tool#n5268From 93d4e7698afc92e3b257c2a0b205

Re: Python 'strings'

Hi Bruno, On 2/25/24 4:02 AM, Bruno Haible wrote: > * The Python interpreter prints strings with single-quotes: > > >>> "abc" > 'abc' > > So, that makes the single-quotes the natural choice. Interesting find. I don't have super strong feelings on the matter. I just think that it is best tha

Re: Python != None

Hi Bruno, On 2/25/24 3:57 AM, Bruno Haible wrote: > The style warnings about "!= None" in pycodestyle and/or pylint are > relativized by this warning in Python itself: > > >>> '' != None > True > >>> '' is not None > :1: SyntaxWarning: "is not" with a literal. Did you mean "!="? > True

Re: Python != None

On 2/25/24 11:29 AM, Collin Funk wrote: > I would hope that it just > involves a simple configuration file that takes the options we have at > the top of gnulib-tool.py. Adding the two attached files to the root directory of gnulib should adjust the warnings to the agreed upon coding

Re: pycodestyle configuration

Hi Bruno, On 2/26/24 12:38 PM, Bruno Haible wrote: > For pycodestyle, a file named '.pycodestyle' would be OK with me as well, > if that works. If not, then how about > - submitting a feature request to the pycodestyle developers, so that > '.pycodestyle' is accepted in addition to of 'pycod

Re: pycodestyle configuration

rned by argparse are used before being assigned to local variables and then used again. Thanks, CollinFrom 900ded124da7b8f5c267dd58b423f119ac1eda2a Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Mon, 26 Feb 2024 16:02:34 -0800 Subject: [PATCH 1/2] gnulib-tool.py: Add configuration files f

Re: pycodestyle configuration

Hi Bruno, On 2/26/24 6:38 PM, Bruno Haible wrote: > But now we have the desired configurations of pycodestyle and pylint > in two places: in comments and in the config files. With the promise that > they will get out of sync in the future. To avoid this, let me > update the comments... True. I th

gnulib-tool.py: Follow gnulib-tool changes, part 29, 30.

if I missed anything. CollinFrom 3d99a44c67c1a7db5bfe210f46ede1eb0700e664 Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Mon, 26 Feb 2024 21:22:23 -0800 Subject: [PATCH 1/2] gnulib-tool.py: Follow gnulib-tool changes, part 29. Follow gnulib-tool change 2021-03-06 Paul Eggert parse-datetime2

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

added to gnulibtool.py.TODO so I've made a reference to it anyways. CollinFrom 983e8e95e90b108a2e126bb2a34d3ee0ad3dd721 Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Tue, 27 Feb 2024 02:01:59 -0800 Subject: [PATCH 3/3] gnulib-tool.py: Follow gnulib-tool changes, part 31. Follow gnulib-tool c

[PATCH] gnulib-tool.py: Fix configure.ac output.

so I will fix the other double quote offenders then. [1] https://docs.python.org/3/library/re.html#raw-string-notation CollinFrom a9932bf82e3b5e1526e801a55f743a0c8aeb2331 Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Tue, 27 Feb 2024 14:15:10 -0800 Subject: [PATCH] gnulib-tool.py: Fix co

Re: [PATCH] gnulib-tool.py: Fix configure.ac output.

Hi Bruno, On 2/27/24 2:39 PM, Bruno Haible wrote: > I guess I wasn't very familiar with raw strings when I did this change. No worries, it was pretty easy to find and fix. I remember a professor in college telling us to always use them for Python regular expressions. It seems this is also recomme

Re: [PATCH] gnulib-tool.py: Fix configure.ac output.

On 2/27/24 3:39 PM, Bruno Haible wrote: > $ pycodestyle *.py > ... > GLEmiter.py:535:26: W605 invalid escape sequence '\.' > GLEmiter.py:535:35: W605 invalid escape sequence '\.' > ... I discovered it that way too. I like using Eglot from Emacs though. If you are using Emacs 29+ the `eglot' comman

Can we have gnulib-tool.py emit the same copyright header?

gnulib-tool.py is not a separate package) [1]. Am I missing something or can we make this change? [1] https://www.gnu.org/prep/maintain/maintain.html#Copyright-Notices Thanks, CollinFrom 202d152d8a0a6fa3875c44ff5cd38bdd4b0d485d Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Tue, 27 Feb 2024 17

Re: Can we have gnulib-tool.py emit the same copyright header?

On 2/27/24 6:07 PM, Bruno Haible wrote: > When I wrote this piece of code (2022-08-05), it was for the --version > output. I had apparently overlooked that the method GLInfo.copyright > also gets used in other contexts than for processing the --version > option. Ah I see. I probably should have gr

Re: Can we have gnulib-tool.py emit the same copyright header?

On 2/27/24 6:26 PM, Bruno Haible wrote: > git log -n 1 ChangeLog | grep ^Date: Ah, I see what is happening. [collin@debian gnulib]$ git log -n 1 commit 431d6a7615245e6b32d95b4b27aab5d3af65ad2b (HEAD -> master, origin/master, origin/HEAD) Author: Bruno Haible AuthorDate: Wed Feb 28 00:33:49

Re: Can we have gnulib-tool.py emit the same copyright header?

On 2/27/24 6:51 PM, Collin Funk wrote: > [collin@debian gnulib]$ git log --pretty=medium -n 1 | grep '^Date:' It seems that the 'git command-name --pretty=medium' existed before git version 1. I've found the commit that introduced the version I was using that caused br

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

rrectly so gnulib-tool and gnulib-tool.py output the same actioncmd (at least with Emac's merge-gnulib). Let me know if I missed anything. CollinFrom 3a7cbd5c95b2d24341865bf101fe8b1a93f83737 Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Wed, 28 Feb 2024 03:33:15 -0800 Subject: [PATCH] gn

Re: Can we have gnulib-tool.py emit the same copyright header?

patch look for fixing the copyright headers? I could have just used constants.__copyright__ in GLEmiter, but I thought it was best to put in GLInfo just in case it is needed elsewhere later. CollinFrom 67a69b85467f1641f5e8741a22c929cdf8268cd8 Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Wed, 2

Re: Can we have gnulib-tool.py emit the same copyright header?

On 2/28/24 1:30 PM, Bruno Haible wrote: > Looks good, except for a typo or spelling mistake. [1] I'm not the greatest at spelling apparently. Attached it with the typo fixed. CollinFrom c21617ca4561f48225543378d0d4e24ac700877b Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Wed, 28 Feb

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

commit/?id=5c51e14ad89c9210536aab61836111962b68fb4f CollinFrom 6b0a5a3203f5ef97a92b82756ee61d81103600e5 Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Wed, 28 Feb 2024 16:35:36 -0800 Subject: [PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 32. Follow gnulib-tool change 2018-10-22 Bruno Haible Fix failure

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

b412f1c82d0fe0815c0d2e51fc Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Wed, 28 Feb 2024 19:05:16 -0800 Subject: [PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 33. Follow gnulib-tool change 2017-03-14 Bruno Haible gnulib-tool: Don't produce a tests directory with

[PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 34, 35

Two more simple patches. The first deals with the @ALLOCA@ substitution for libtests.a. The second just bumps the Autoconf requirement to 2.64. CollinFrom 6a59d2ca97f111c5ca7dd564c5d92f62a5e196d7 Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Wed, 28 Feb 2024 21:17:49 -0800 Subject: [PATCH 2/3

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

Hi Bruno, On 2/29/24 2:48 AM, Bruno Haible wrote: > One question: Why this change? > > -tests_modules = sorted(set(tests_modules)) > +tests_modules = sorted(list(set(tests_modules))) > > IMO, it is redundant, because sorted() of a set returns a list anyway. Ah, I had a feeling t

Re: Python type annotations

On 2/29/24 7:10 AM, Bruno Haible wrote: > Argument tests like we have them: > >if type(actioncmd) is not str: > > are perfectly OK to use. Simple and straightforward. > > is_iterable feels a bit like fashion: You can use them if you want to be > fashonable and have extra money to spend :

Re: Python type annotations

On 2/29/24 8:16 AM, Kévin Le Gouguec wrote: > * the former provide some runtime sanity-checking, > * the latter are ineffective at runtime, and exist mainly for the > programmer's benefit (IDE hints for completion, documentation, > linting, etc). > > (Though linters like mypy do _also_ pick up

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

eSystem.py | 9 - 3 files changed, 10 insertions(+), 23 deletions(-) diff --git a/ChangeLog b/ChangeLog index f4c78b8666..9536c174f8 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,13 @@ +2024-02-29 Collin Funk + + gnulib-tool.py: Follow gnulib-tool changes, part 36. + Fol

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

re.html#re.compile CollinFrom 4b792e51ede2559e3a9c90ab6a6605e2ecceeb1f Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Thu, 29 Feb 2024 18:15:19 -0800 Subject: [PATCH 2/3] gnulib-tool.py: Follow gnulib-tool changes, part 37. Follow gnulib-tool change 2018-10-22 Bruno Haible Assume Automake &g

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

On 2/29/24 6:58 PM, Collin Funk wrote: > The second fixes a problem I noticed when using the Emacs merge-gnulib > script. I noticed that most of the Automake conditionals for header > files weren't being converted to GNU Make syntax. The diff would have > many lines like this: I

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

On 3/1/24 3:51 AM, Bruno Haible wrote: > Interesting. One can use 'git diff --no-index' even outside a git repository. > Is there any significant advantage of 'git diff --no-index' over > 'diff -u --color'? I mostly type it out of habit to be honest. Not sure why I started using it. My git diff se

Re: --create-testdir speed

On 3/1/24 6:13 AM, Bruno Haible wrote: > On an ASUS UX305CA-FC093T (a notebook) from 2017, I remember that it took > about 45 minutes. On the Fujitsu ESPRIMO G7012A that I own now, it takes > about 17 minutes. That sounds similar to my experience. > --create-megatestdir with all modules is not re

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

From: Collin Funk Date: Fri, 1 Mar 2024 23:39:26 -0800 Subject: [PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 38. Follow gnulib-tool change 2020-12-26 Bruno Haible gnulib-tool: Make --conditional-dependencies work with --with-tests. * pygnulib/GLEmiter.py

Best way to solve this diff between gnulib-tool and gnulib-tool.py?

When testing the last patch I noticed that gnulib-tool and gnulib-tool.py output file lists assigned to Make variables in a different order. Here is an example: $ gnulib-tool --create-testdir --dir test-shell fts $ gnulib-tool.py --create-testdir --dir test-python fts $ git diff --no-index test-py

Re: Best way to solve this diff between gnulib-tool and gnulib-tool.py?

overflow.com/a/17016257 CollinFrom ec9b5cd9d3132fe35c8b8c1c947bcc143403d0a3 Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Sat, 2 Mar 2024 04:59:04 -0800 Subject: [PATCH] gnulib-tool.py: Make output of test Makefile.am match gnulib-tool. * pygnulib/GLModuleSystem.py (GLModule.getAutomak

[PATCH] gnulib-tool.py: Fix output of gnulib-comp.m4.

nulib.git/tree/pygnulib/GLEmiter.py#n181 CollinFrom ae593ef0dc43ed0260523b611eb0675dabaefe00 Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Sat, 2 Mar 2024 18:43:26 -0800 Subject: [PATCH] gnulib-tool.py: Fix output of gnulib-comp.m4. * pygnulib/GLEmiter.py (GLEmiter.autoconfSnippets): Fix indent

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

On 3/2/24 7:02 PM, Collin Funk wrote: > When working on the one of the TODO entries I noticed that > the gnulib-comp.m4 output was incorrect. Here is the item I was working on. I _think_ I understood it correctly but you guys are much more talented at shell than me. :) Specifically, I was

Re: [PATCH] gnulib-tool.py: Fix output of gnulib-comp.m4.

Hi Bruno, On 3/3/24 2:34 AM, Bruno Haible wrote: > There are no problems with writing "condition != True". Remember the rule? > 'condition' as a variable can hold the values None, True, or a string. > Thus it has to be compared with == or !=. Yes, I was overthinking it. :) > "condition != True"

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

On 3/3/24 4:30 AM, Bruno Haible wrote: > In the original commit, I removed the error message > "option --conditional-dependencies is not supported with --with-tests" > only at one place (the command-line option checks), but left it in > func_import. > You are removing it in both places (mode == 'i

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

On 3/3/24 4:30 AM, Pádraig Brady wrote: > Right, join without options is essentially set intersection. > See https://www.pixelbeat.org/cmdline.html#sets Thanks for the examples. Bookmarked it since it will probably come handy as I work on gnulib-tool. :) Collin

[PATCH] gnulib-tool.py: Adjust construction of configure.ac path.

it.savannah.gnu.org/cgit/gnulib.git/tree/gnulib-tool#n1597 CollinFrom 0343d44ada1c1b0d50ad4b90efa10d596f03c5b0 Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Sun, 3 Mar 2024 16:00:57 -0800 Subject: [PATCH] gnulib-tool.py: Adjust construction of configure.ac path. * pygnulib/GLConfig.py (GLC

[PATCH] doc: Fix build errors.

to be the original intent. CollinFrom 412c885c9bab2f2c32aa1bc28aed7a7f570fd4ad Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Mon, 4 Mar 2024 05:09:51 -0800 Subject: [PATCH] doc: Fix build errors. * doc/gnulib-tool.texi (Style of #include statements): Use @itemize w{} instead of the

Re: [PATCH] doc: Fix build errors.

On 3/4/24 9:29 AM, Bruno Haible wrote: > The texinfo developers recommend to use > @itemize @asis{} > This workaround is more straightforward than @itemize @w{}. Agreed. Thanks for the fix. Collin

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

heck is still performed when mode != 'import'. CollinFrom 5dd9572597ada0790d9b9d9911c433fd25dca092 Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Mon, 4 Mar 2024 12:35:15 -0800 Subject: [PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 39. Follow gnulib-tool change 2017-12-28 Bruno Haible g

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

lf.emitter.tests_Makefile_am' instead of 'self.emitter.lib_Makefile_am'? https://git.savannah.gnu.org/cgit/gnulib.git/tree/pygnulib/GLImport.py#n1282 https://git.savannah.gnu.org/cgit/gnulib.git/tree/gnulib-tool#n6174 CollinFrom ce0134f107655906963888080b6a3cb314b4ac97 Mon Sep 17 00:00:00 2001 From: Co

[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 >

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 41.

ary['var'] == 'SUBDIRS' and dictionary['dotfirst']: which should match the original commit. CollinFrom c7257b6ae39c23425db09fff5a6dcf0fae45de01 Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Tue, 5 Mar 2024 16:30:20 -0800 Subject: [PATCH] gnu

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

=libgnu \ # --source-base=lib \ # --m4-base=m4 \ The actioncmd already handles the comment '#' so we don't need another when outputting in gnulib_cache. CollinFrom ec722d1deb398d4f0f2ce526db5444543dd4bad4 Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Tue, 5 Mar 2024 20:32:2

gnulib-tool.py: Follow gnulib-tool changes, part 43, 44.

. The library is just the dummy module and the tests are vc-list-files. CollinFrom 1ec490bdc80f64d63ce7177114fcecfc50d460db Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Tue, 5 Mar 2024 23:47:08 -0800 Subject: [PATCH 3/4] gnulib-tool.py: Follow gnulib-tool changes, part 43. Follow gnulib-tool

Re: gnulib-tool.py: Follow gnulib-tool changes, part 43, 44.

On 3/6/24 12:26 AM, Collin Funk wrote: > gnulib-tool.py --create-testdir --dir test-python readme-release > gnulib-tool --create-testdir --dir test-shell readme-release > git diff --no-index test-python/gltests/Makefile.am > test-shell/gltests/Makefile.am While running that I not

Re: gnulib-tool.py: Follow gnulib-tool changes, part 43, 44.

Hi Bruno, On 3/6/24 3:22 AM, Bruno Haible wrote: > Thanks, applied. (With an extra newline, just to make it clear that the > %s/%s/%s.%s arguments are the same in all three cases. Could be simplified > in the future, but that's not a priority now.) I assumed the intent of the original code was to

gnulib-tool.py: Follow gnulib-tool changes, part 45, 46.

eeded for the %reldir% replacements. Since the header stuff depends on a few more changes, currently it just removes a few lines of the diff for me while testing. CollinFrom e6b9a208c5f911a138adbc350caca46b38c30a0b Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Wed, 6 Mar 2024 21:49:21 -08

gnulib-tool.py: Fix errors when executing --create-megatestdir.

uld work properly now. CollinFrom ac8654c35c8b6ee49106d5e120839407ae47ffe0 Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Thu, 7 Mar 2024 03:11:55 -0800 Subject: [PATCH 3/3] gnulib-tool.py: Fix errors when executing --create-megatestdir. * pygnulib/GLTestDir.py (GLMegaTestDir.execute): Create a

Re: gnulib-tool.py: Fix errors when executing --create-megatestdir.

On 3/7/24 3:51 AM, Bruno Haible wrote: > Indeed, when there are such typos in the code, you know that it has not > been tested. No worries. 99% of the work was done for me there. I assumed someone committed with the intent of coming back to it but forgot. Collin

Question about 'gen-header' module and friends.

Hello, I was about to start working on gnulib-tool.py a bit more today and remembered seeing something I wanted to ask about. When creating a testdir that uses system headers, you see the following lines when diff'ing 'gltests/Makefile.am' from each implementation: # Use $(gl_V_at) instead of $(

Re: Question about 'gen-header' module and friends.

On 3/7/24 6:10 PM, Collin Funk wrote: > I have not implemented it yet in gnulib-tool.py so the snippet is just > copy and pasted from the module. The part I wanted to ask about was > the second line of the comment which is removed by gnulib-tool. Should > the sed invocations [1] be cha

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

://peps.python.org/pep-0008/#descriptive-naming-styles CollinFrom 9f290777ec05cb5e81d77d54b69cd68b68fbcf49 Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Fri, 8 Mar 2024 01:43:26 -0800 Subject: [PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 47. Follow gnulib-tool changes 2021-12-

[PATCH] gnulib-tool: Don't remove comments referencing @NMD@.

Hi Bruno, Thanks for double checking the @NMD@ thing for me. Here it is with a ChangeLog entry. CollinFrom ace1c35cc1aa535396e606499e44c0bc1847b340 Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Fri, 8 Mar 2024 02:28:11 -0800 Subject: [PATCH 2/2] gnulib-tool: Don't remove comments refere

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

On 3/8/24 4:02 AM, Bruno Haible wrote: > Thanks for mentioning this; I did not know about this property of 'import *' > statements. I didn't know about the import property until recently either. I always knew of the naming convention though. I don't think we use 'import *' anywhere and I tend to a

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

ese to GLError.py. I think that something like raise GLError(GLErrno.PATCH_FAILED, 'message') would be more readable than raise GLError(20, 'message') Sort of like errno.h but without the portability issues. :) [1] https://docs.python.org/3/library/enum.html Colli

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

On 3/8/24 9:47 PM, Collin Funk wrote: > These lines are fixed by this patch on my updated GNU/Linux machine. I > saw another TODO item referencing a separate patch needed for > test-driver distributed with a specific version of Automake. I'll get > around that one in a bit,

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

loca.c' in "$tmp"/new-files to test the second conditional [1]. Feel free to let me know if there is an easy way to do it. [1] https://git.savannah.gnu.org/cgit/gnulib.git/tree/gnulib-tool#n6044 CollinFrom 7d04cbcec2363a646d83b3012584edba538d97b6 Mon Sep 17 00:00:00 2001 From: Collin Funk Dat

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

s]) in configure.ac instead of: AUTOMAKE_OPTIONS = subdir-objects in Makefile.am. I think that should be a pretty easy change so I will try to get it done sometime today. CollinFrom 9de14a0336819bf5eac7c083615e8f54094ce76b Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Sat, 9 Mar 2024 18:12:5

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

On 3/9/24 6:28 PM, Collin Funk wrote: > I think that should be a pretty easy change so I will try to get it > done sometime today. Not the cleanest code I have ever written but it seems to work. :) Here is a test case: gnulib-tool.py --create-testdir --dir test-python dummy gnulib-tool --

[PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 53, 54.

On 3/9/24 8:15 PM, Collin Funk wrote: > I don't remember those changes looking too hard, so _hopefully_ I can > get them done soon. The first two patches deal with the @NMD@ and @!NMD@ replacements. I used a mix of the test cases from my previous emails and the Emacs merge-gnulib scri

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

Hi Bruno, > Also, please don't drop comments that are present in the original code, such > as: > > # Replace NMD, so as to remove redundant "$(MKDIR_P) '.'" invocations. > # The logic is similar to how we define gl_source_base_prefix. Sure. I remember seeing that comment in the shell script

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

and >gl_source_base_prefix. Because these are really hard to grasp without a >comment. I agree. I assume that you mean the ones that are written in the shell script? I forgot to copy and paste those. I am still learning how gnulib-tool works so it is a bit hard for me to add origin

Re: planning for beta-testing gnulib-tool.py

Hi Simon and Bruno, On 3/10/24 7:00 PM, Bruno Haible wrote: > I think this would be a reasonable time after having made the Python > implementation > the default. I expect every package maintainer to run 'gnulib-tool' at least > once > in two years and report problems if they occur. Based on thi

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

Hi Bruno, On 3/10/24 3:51 PM, Bruno Haible wrote: > I prefer comparing with '' explicitly. It's clearer about the intent. > It avoids an implicit conversion from str to bool. Sure, makes sense. I'll keep that in mind in the future. > Regarding the regex change: In a group '(...)' one needs to us

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

But I did not do it this patch since it would make the changes harder to follow. CollinFrom c0772b3fe45a61dc686ce945e6decfb7ff4a84c4 Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Sun, 10 Mar 2024 21:50:59 -0700 Subject: [PATCH 2/2] gnulib-tool.py: Follow gnulib-tool changes, part 52. Follow gn

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

ake check in Coreutils with both Python version 3.7 and 3.12. [1] https://docs.python.org/3/tutorial/datastructures.html#list-comprehensions [2] https://docs.python.org/3/library/__future__.html CollinFrom 49596fc1f103f5bdff2529c3506c6eb783f4de4d Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Mon, 11 Mar 2024

gnulib-tool.py --add-import fails

Hi Simon, On 3/11/24 1:06 AM, Simon Josefsson wrote: > Trying gnulib-tool.py on OATH Toolkit (which use a somewhat unorthodox > gnulib usage style by adding code into git) results in error below. I > thought it was a missing mkdir at some point, but I couldn't find a > solution... ideas? I was g

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

On 3/11/24 4:57 AM, Bruno Haible wrote: > This looks good to me. 'sed' accepts POSIX BREs, where '(' and '[' stand for > the literal '(' and '[' characters unless escaped. Thanks for double checking for me. > Also, I applied the attached follow-up, in order to make the logic of the code > easier

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

On 3/11/24 5:37 AM, Bruno Haible wrote: > There is a pitfall with the list.join('\n') idiom: it's mainly designed for > non-empty lists. I therefore add the patch below. Ah, I see what you mean. I didn't even think of this case... Good catch. Thanks. Collin

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

Hi Bruno, On 3/11/24 4:32 AM, Bruno Haible wrote: > Another GNU package in the same realm is GNU Bison. If you like regular > expression and automata theory, you will like GNU Bison as well. Thanks for the suggestion. I've never gotten around to using YACC or GNU Bison, surprisingly. I'll find so

Re: gnulib-tool.py --add-import fails

On 3/11/24 2:46 AM, Collin Funk wrote: > So I think it is safe to say the problem occurs somewhere around > there... All of those modules are Coreutils --local-dir modules. Then > dynamic typing things happen. I just started looking into this issue a bit more. With a clean Coreutils dir

Cause of --add-import issue and proposed solution

Hello, I have discovered the cause of the --add-import issue. It is simpler than I originally thought. It seems that a code path is taken where the value of 'sourcebase' in the GLConfig is not set. Then in GLImport.rewrite_new_files this line is taken: path = constants.substart('lib/', '%s/'

  1   2   3   4   5   6   7   8   >