Hi Bruno, On 3/20/24 3:58 AM, Bruno Haible wrote: > * If an Automake snippet has a blank line, we want that blank line to be > preserved in the generated Makefile.am, not eliminated.
Ah, okay I see. I agree that it is best to preserve whitespace here. I didn't see any '\v', '\f', etc. in the modules. But if the author of the module put it there, it is best that gnulib-tool.py respects their wishes. > Then, we can make optimizations and other refactorings, checking each > commit against the test suite. (That's what the test suite is made for!) Sure, makes sense to me. I'll focus on finishing gnulib-tool.py.TODO. I beleive I found the cause of this issue: diff --git a/lib/gnulib.mk.in b/lib/gnulib.mk.in index 6df7f6d9b00..49ca3229728 100644 --- a/lib/gnulib.mk.in +++ b/lib/gnulib.mk.in @@ -3296,7 +3296,9 @@ ifneq (,$(GL_COND_OBJ_STDIO_WRITE_CONDITION)) libgnu_a_SOURCES += stdio-write.c endif -EXTRA_DIST += stdio.in.h +EXTRA_DIST += stdio-read.c stdio.in.h + +EXTRA_libgnu_a_SOURCES += stdio-read.c endif ## end gnulib module stdio Which is not documented in gnulib-tool.py.TODO. I'll submit a patch for that later today because it probably causes issues in more areas. 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 unexpected differences. I believe that the .gitignore in each *-result directory will ignore '*~' because this is nearly always intended. Ideally we would want to make sure the backup files are the same, but for now does it make more sense to clean them? I'm not sure how strict you are with the maint-tools repository, but maybe these tests would be better in a different repository? Then we wouldn't have to worry about littering in that one. :) Collin
