On 3/21/24 7:29 PM, Bruno Haible wrote:
> I've now added the 'test-hello-c-gnulib-automakesubdir-withtests-1.sh'
> test, among others. With this, I think adding Bison is redundant.
Thanks. I'll look into the Bison error once gnulib-tool.py.TODO is
done and more tests pass.
Collin
On 3/21/24 7:03 PM, Bruno Haible wrote:
> I prefer to remove the redundant space. So, I took your diff, completed it,
> committed it in your name, and updated the unit tests.
Thanks! The --avoid case with no equal wasn't on my screen so I didn't
see it...
Collin
Hi Collin,
> It might be worth adding
> GNU Bison as a test case. It has not had a commit since Nov 4 2022,
> but builds fine running:
>
> $ git submodule update --init
> $ env GNULIB_TOOL_IMPL=sh ./bootstrap
> $ ./configure
> $ make all
>
> But the Python version will fail to run 'make all' due
Hi Collin,
> There is a minor whitespace diff in gnulib-cache.m4 for avoided
> modules. For example, after running 'test-emacs-1.sh', we see
> (omitting many entries because long lines):
>
> --- ./test-emacs-1.result/m4/gnulib-cache.m4 2024-03-21 17:47:04.460177611
> -0700
> +++ tmp1158700-resu
There is a minor whitespace diff in gnulib-cache.m4 for avoided
modules. For example, after running 'test-emacs-1.sh', we see
(omitting many entries because long lines):
--- ./test-emacs-1.result/m4/gnulib-cache.m42024-03-21 17:47:04.460177611
-0700
+++ tmp1158700-result/m4/gnulib-cache.m4
Hi Bruno,
I assume you are using Autoconf 2.72? I don't see an easy way to fix
this and Autoconf is trivial to install so it is probably just worth
mentioning in the README.
$ /usr/bin/autoconf --version
autoconf (GNU Autoconf) 2.71
$ env GNULIB_TOOL_IMPL=py AUTOCONF=/usr/bin/autoconf ./test-emac
Hi Bruno,
On 3/21/24 2:26 PM, Bruno Haible wrote:
> if extra_files != [''] and extra_files:
> if extra_files != ['']:
> if buildaux_files != ['']:
>
> Why does [''] represent the empty set/list here? Is something wrong with the
> function filter
Hi Bruno,
On 3/21/24 8:45 AM, Bruno Haible wrote:
> Oh, indeed, the unit test works in the directory in which I committed it,
> but does not work in a fresh git checkout :-( The .gitignore files
> cause a lot of trouble. But it should be fixed by now.
Thanks! I see you also fixed the 'autom4te.ca
Hi Collin,
> This patch seems correct to me and allows me to do this for the first
> time:
>
> $ env GNULIB_TOOL_IMPL=sh ./admin/merge-gnulib
> $ git add .
> $ rm -rf *
> $ git restore .
> $ env GNULIB_TOOL_IMPL=py ./admin/merge-gnulib
> $ git status
> On branch master
> Your branch is up to date
Hi Bruno,
On 3/21/24 9:00 AM, Bruno Haible wrote:
> Thanks. So, we are still finding logic bugs... Which proves that the
> test suite is necessary. I don't think we would have found this typo
> by mere code review (within a finite time).
Yes, agreed. The info-tests/* are very quick so it is easy
Hi Bruno,
On 3/21/24 8:50 AM, Bruno Haible wrote:
> Thanks, applied. With a small tweak in main.py, to make the 3 added files
> more symmetric:
Looks good. I was conflicted on whether or not to do this in the
original patch.
Collin
Hi Collin,
> This patch fixes the failure of
> 'test-extract-recursive-link-directive-3.sh' in the gnulib-tool test
> suite:
>
> cmp: EOF on tmp529181-out which is empty
> --- ./test-extract-recursive-link-directive-3.output 2024-03-20
> 19:16:08.842291576 -0700
> +++ tmp529181-out 2024-03-
Hi Collin,
> This patch makes the python version behave the same way as well.
> I'm not sure if any files in modules/* have extra newlines like this,
> but the more close the gnulib-tool's behave the better.
Thanks, applied. With a small tweak in main.py, to make the 3 added files
more symmetric:
Hi Collin,
> I've been using the test case a bit and noticed this slight issue:
>
> $ env GNULIB_TOOL_IMPL=sh ./test-emacs-1.sh
> ...
> Only in tmp49208-result/m4: wchar_t.m4~
> Only in tmp49208-result/m4: xattr.m4~
> Only in tmp49208-result/m4: zzgnulib.m4~
> FAIL: gnulib-tool's result has unexp
In the test suite, in the test-wget2-1.sh test, I see a strange behaviour:
After removing /GNUmakefile, /maint.mk, lib from the initial .gitignore file,
gnulib-tool reflects the addition of GNUmakefile and maint.mk in the
.gitignore file, but does not do so for the added files in lib/. Which makes
> Am 20.03.2024 um 23:23 schrieb Paul Eggert :
>
> On 3/20/24 01:51, Peter Dyballa wrote:
>> I was asking this myself: What is this test good for? It's possibly 15 years
>> after it was introduced?
>
> If old glibc versions are no longer worth worrying about, a similar argument
> would apply
16 matches
Mail list logo
