Collin Funk wrote:
> Here is a simple patch that fixes the conditionals when using
> --gnu-make.
Thanks, applied.
Bruno
Hi Collin,
> After that we get the following diff:
This is much nicer indeed.
I have applied the 0002-* patch.
Bruno
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
>
>
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
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 &
bmissing/libmissing.a
+LDADD = ../../libmissing/libmissing.a
Which is less incorrect. :)
CollinFrom 6eead93425dba15bf7aeb08733256f7e1661a482 Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Tue, 5 Mar 2024 01:55:08 -0800
Subject: [PATCH 1/2] gnulib-tool.py: Follow gnulib-tool changes, part 41.
F
llin Funk
Date: Mon, 4 Mar 2024 21:26:08 -0800
Subject: [PATCH] gnulib-tool.py: Follow gnulib-tool changes, part 40.
Follow gnulib-tool change
2021-12-18 Bruno Haible
stdint: Fix handling of limits.h (regression 2021-12-16).
* pygnulib/GLEmiter.py (GLEmiter.lib_Makefile_am)
(GLEmiter.tests_Make
Hi Collin,
> The error should only be removed in mode == 'import' correct?
Yes.
Patch applied. Thanks!
Bruno
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
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
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
Hello Collin,
> -for m in $modules; do echo $m; done | LC_ALL=C sort -u > "$tmp"/modules
> +for m in $referenceable_modules; do echo $m; done | LC_ALL=C sort -u >
> "$tmp"/modules
>
> Which I didn't understand until seeing this line [1]:
>
> deps=`for m in $deps; do echo $m; done | LC_A
On 03/03/2024 05:33, Collin Funk wrote:
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
Hi Collin,
> This patch pretty much copy and pastes a lot of code used from
> GLEmiter.lib_Makefile_am into GLEmiter.tests_Makefile_am.
Thanks, I am applying it, together with a fix: When doing copy&paste,
one needs to do it _mutatis mutandis_.
2024-03-03 Bruno Haible
gnulib-tool.py
issing something.
[1]
https://git.savannah.gnu.org/cgit/gnulib.git/tree/gnulib-tool?id=589e96475f8f2d21a83405ab0672ce95091b80e5#n4296
CollinFrom bf4cfc143601f17133238a32de68ca033fa1b757 Mon Sep 17 00:00:00 2001
From: Collin Funk
Date: Sat, 2 Mar 2024 21:02:15 -0800
Subject: [PATCH] gnulib-tool.py:
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
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
Thanks! Both patches applied.
Bruno
Collin Funk wrote:
> Follow gnulib-tool change
> 2017-03-14 Mathieu Lirzin
> gnulib-tool: don't automatically distribute files from top/
Thanks. Applied.
> git diff --no-index test-python/gllib/Makefile.am test-shell/gllib/Makefile.am
Interesting. One can use 'git diff --no-index' even outsid
er.lib_Makefile_am): Reduce code
+ duplication. Use re.MULTILINE so '^' matches the start of each line
+ instead of only the start of a string.
+
2024-02-29 Collin Funk
gnulib-tool.py: Follow gnulib-tool changes, part 37.
diff --git a/pygnulib/GLEmiter.py b/pygnulib/GLEmiter.py
index 64
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
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
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
Collin Funk wrote:
> Two more simple patches. The first deals with the @ALLOCA@
> substitution for libtests.a. The second just bumps the Autoconf
> requirement to 2.64.
Perfect. Thanks. Applied.
Bruno
Hi Collin,
> This patch explains the random tests/ directory that gnulib-tool.py
> makes with the Emacs script. I've tried to make this patch match the
> shell code.
Thanks! Applied.
> Also, I've noticed that some functions check if a type(var) == list.
> To avoid problems I've returned an empty
] gnulib-tool.py: Follow gnulib-tool changes, part 34.
Follow gnulib-tool change
2017-05-15 Bruno Haible
gnulib-tool: Fix generated code when libtests contains module 'alloca'.
* pygnulib/GLEmiter.py (GLEmiter.tests_Makefile_am): Use @ALLOCA@ for
libtests.a instead of @LTALLOCA@.
---
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
Thanks! Applied.
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
Collin Funk wrote:
> I've also removed the sorted() calls in actioncmd. The sorting in
> __init__ works correctly so gnulib-tool and gnulib-tool.py output the
> same actioncmd (at least with Emacs' merge-gnulib).
Thanks for following up on this. The patch looks good. Applied.
Bruno
On 2/26/24 12:51 PM, Bruno Haible wrote:
> Well, GLConfig applies to all modes (not just 'import', but also
> 'create-testdir' etc.). Since on the bash side, you found that the
> sorting is specifically in the func_import(), the right place to do it
> is in GLImport.py, not GLConfig.py.
I think th
Collin Funk wrote:
> And another patch to stop gnulib-tool.py from messing with copyright
> headers. This patch is just doing the same as this commit did for
> gnulib-tool:
>
> https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=f3553bdefc9202e81996c73686e3ca53cd827417
Thanks! The gnu_make tw
Collin Funk wrote:
> These two TODO entries were pretty simple. One of the ChangeLog
> entries listed to a test case Bruno wrote that worked for testing both
> of them.
>
> [collin@debian gnulib]$ gnulib-tool.py --create-testdir --dir=testdir-all
> --single-configure
> module parse-datetime2 depe
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
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
Hi Collin,
> From what I could understand, it seems that upon seeing that the mode
> is "import", the specified_modules is set with the unsorted list of
> modules [1]. Then that variable is sorted before it is used [2]. Could
> you confirm that I am understanding this correctly?
Yes, I confirm. S
(GLImport.actioncmd): Don't sort modules when
+ constructing actioncmd as GLConfig handles it for us.
+
2024-02-24 Collin Funk
gnulib-tool.py: Follow gnulib-tool changes, part 28.
diff --git a/pygnulib/GLConfig.py b/pygnulib/GLConfig.py
index bdebf243cc..03da6f8e3c 100644
--- a/pygn
Hi Bruno,
The pythonic way is
mode is not None
rather than
mode != None
(the reason is None is an object)
Just in case,
Dima
On 24 February 2024 23:25:51 GMT, Bruno Haible wrote:
>Hi Collin,
>
>> > I.e. you meant to write
>> > mode != None
>> > not
>> > modules != None
>> > ?
>
Collin Funk wrote:
> So the --avoid modules are emitted in the order they are passed to
> gnulib-tool, but the actual modules will be alphabetically sorted.
> Therefore, I think the correct code would be:
>
> if len(avoids) > 0:
> actioncmd += ''.join([f" \\\n# --avoid={x}" for x in avoids])
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 before the actioncmd step in gnulib-too
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-
Hi Collin,
> 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.
Thanks! Applied.
Only one question on this one:
> +if len(avoids) > 0:
> +actioncmd += ''.join([f"
Hi Collin,
> > I.e. you meant to write
> > mode != None
> > not
> > modules != None
> > ?
>
> The second fixes this typo. Thanks for noticing it.
But there's another typo in the same line: The original code
case $mode,$gnu_make in
*test*,true)
echo "gnulib-tool: --gnu-make not s
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
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
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
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?
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
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
Collin Funk wrote:
> For this change gnulib-tool had to be updated to emit an
> empty assignment of EXTRA_PROGRAMS at the top of $test_dir/Makefile.am.
> This prevents Automake from warning about it not being previously set.
>
> This change is trivial but here is a test case just to confirm.
Than
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.
On Samstag, 9. September 2017 09:51:01 CEST Eric Blake wrote:
> On 09/09/2017 09:38 AM, Bruno Haible wrote:
> > Hello Tim,
> >
> >> So if you remove it from bootstrap, I'll update bootstrap in our project
> >> main dir and that's it.
> >
> > No, we don't remove it from 'bootstrap'. This piece of
over, process invocation is quite a dumb technique when you have
built-in
language features instead.
2017-09-09 18:41 GMT+03:00 Bruno Haible :
> Hi Dmitry,
>
> > > [PATCH 6/6] gnulib-tool.py: follow gnulib-tool changes, part 14
> > > gnulib-tool: don't transform bi
Hi Dmitry,
> > [PATCH 6/6] gnulib-tool.py: follow gnulib-tool changes, part 14
> > gnulib-tool: don't transform binary files with sed
> All these sed transformers shall be IMHO entirely deprecated. I don't quite
> remember why I used sed
Using 'sed' is a
Hi Bruno,
thanks for these patches. I've left some comments below.
> [PATCH 6/6] gnulib-tool.py: follow gnulib-tool changes, part 14
> gnulib-tool: don't transform binary files with sed
All these sed transformers shall be IMHO entirely deprecated. I don't quite
remember w
Hi Dmitry,
Here's the next round of patches, for your review. I'm slowly working through
the past gnulib-tool changes.
Bruno
>From 5aa8b0d419518889a8d6f392c2d38fdd438ce39f Mon Sep 17 00:00:00 2001
From: Bruno Haible
Date: Sat, 9 Sep 2017 12:01:28 +0200
Subject: [PATCH 1/6] gnulib
On 09/09/2017 09:38 AM, Bruno Haible wrote:
> Hello Tim,
>
>> So if you remove it from bootstrap, I'll update bootstrap in our project
>> main
>> dir and that's it.
>
> No, we don't remove it from 'bootstrap'. This piece of backward-compatibility
> code is not expensive to keep.
>
>> @Bruno Ma
Hello Tim,
> So if you remove it from bootstrap, I'll update bootstrap in our project main
> dir and that's it.
No, we don't remove it from 'bootstrap'. This piece of backward-compatibility
code is not expensive to keep.
> @Bruno Maybe it would be wise to just have a symlink to gnulib/build-aux
Hi Dmitry,
Thanks for the reviews.
> Because right now it is a no-op, but parser still doesn't bark when it
> founds it.
> The current behavior of gnulib-tool.py matches the same of gnulib-tool.
> Once you will apply the change, parser shall complain on unknown
> --no-changelog,
Good point. I mi
On Samstag, 9. September 2017 13:08:09 CEST Dmitry Selyutin wrote:
> Hi Bruno,
>
> I have only one question regarding --no-changelog option.
> Are you sure you want to entirely deprecate it?
> Because right now it is a no-op, but parser still doesn't bark when it
> founds it.
> The current behavio
Hi Bruno,
I have only one question regarding --no-changelog option.
Are you sure you want to entirely deprecate it?
Because right now it is a no-op, but parser still doesn't bark when it
founds it.
The current behavior of gnulib-tool.py matches the same of gnulib-tool.
Once you will apply the chan
stakes in these patches.
Bruno
>From e40de420ae64e970376bcfe25105e3ba1f0efbbc Mon Sep 17 00:00:00 2001
From: Bruno Haible
Date: Fri, 8 Sep 2017 23:59:29 +0200
Subject: [PATCH 05/16] gnulib-tool.py: follow gnulib-tool changes, part 1
* pygnulib/GLInfo.py: Follow gnulib-tool change from 2012-
Hi,
I made the following changes to gnulib-tool:
- Fixed the speed problem that some of you noticed. O(N) instead of O(N²).
- Made --with-tests work also with --import, not just with --create-testdir
and --create-megatestdir.
- Option --dry-run now behaves more reasonably.
- The docume
Simon Josefsson wrote:
> There is a --symbolic parameter for gnulib-tool, so I thought copying
> the files should be the default.
>
> Is this intentional?
It was unintentional, and fixed last week too. Sorry.
Bruno
___
bug-gnulib mailing list
bug-gnu
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> >> It should default to 'libgnu'
>> >
>> > Yes. Fixed now as well.
>>
>> It doesn't seem to work:
>>
>> [EMAIL PROTECTED]:~/src/gnutls$ gnulib-tool --import --source-base=gl
>> --m4-base=gl/m4 --lgpl getline error memmem getpass
Simon Josefsson wrote:
> >> It should default to 'libgnu'
> >
> > Yes. Fixed now as well.
>
> It doesn't seem to work:
>
> [EMAIL PROTECTED]:~/src/gnutls$ gnulib-tool --import --source-base=gl
> --m4-base=gl/m4 --lgpl getline error memmem getpass minmax snprintf memmove
> readline gnulib-tool: ***
Bruno Haible <[EMAIL PROTECTED]> writes:
>> [EMAIL PROTECTED]:~/src/gnutls$ gnulib-tool --import --macro-prefix=lgl
>> --source-base=lgl --m4-base=lgl/m4 memmem gnulib-tool: *** missing --lib
>> option
>> gnulib-tool: *** Stop.
>> [EMAIL PROTECTED]:~/src/gnutls$
>>
>> It should default to 'libgnu'
Bruno Haible <[EMAIL PROTECTED]> writes:
> Fixed now.
...
> Yes. Fixed now as well.
...
>> What are these *.tmp files?
>
> The contain the contents of the file to install. Forgot to remove them.
> Now also fixed.
Thanks!
>> lgl/Makefile.am:18: required file `lgl/memmove.c' not found
>> lgl/Makef
Simon Josefsson wrote:
> I'll use GnuTLS as the test subject for this. First impressions:
>
> [EMAIL PROTECTED]:~/src/gnutls$ gnulib-tool --import
> gnulib-tool: *** missing --source-base option
> gnulib-tool: *** Stop.
> [EMAIL PROTECTED]:~/src/gnutls$
>
> That used to work
Fixed now.
> Then I
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> Yup, I'm using two configure.ac's in gsasl, but I don't want to change
>> gnutls to use the same scheme for only this reason. And with your
>> work, I don't have to.
>
> OK, can you try it? The essential changes are already in C
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> Yup, I'm using two configure.ac's in gsasl, but I don't want to change
>> gnutls to use the same scheme for only this reason. And with your
>> work, I don't have to.
>
> OK, can you try it? The essential changes are already in C
Simon Josefsson wrote:
> Yup, I'm using two configure.ac's in gsasl, but I don't want to change
> gnutls to use the same scheme for only this reason. And with your
> work, I don't have to.
OK, can you try it? The essential changes are already in CVS.
> >> How about storing the parameters in the
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> Yay! I considered dropping use of gnulib in libgnutls yesterday,
>> because I wanted the error module for the tools, but that module need
>> a program_name variable. When the library didn't provide one, there
>> were linker fai
Simon Josefsson wrote:
> Yay! I considered dropping use of gnulib in libgnutls yesterday,
> because I wanted the error module for the tools, but that module need
> a program_name variable. When the library didn't provide one, there
> were linker failures. I added a dummy 'char *program_name = "g
Bruno Haible <[EMAIL PROTECTED]> writes:
> 2) Support for multiple gnulib directories with a single configure.ac.
>
> It happens that a project wants to use gnulib in different parts, sometimes
> even with different licenses, but these parts share the same config.h and
> therefore the same configu
Hi all,
In the next days, I'll commit a few significant changes to gnulib-tool's
--import functionality.
1) Ease of use
"gnulib-tool --import" shall be usable for four purposes:
- For making the first use of gnulib in a package, updating configure.ac,
Makefile.am etc.
- For changing the
101 - 176 of 176 matches
Mail list logo
