Paul Eggert wrote: > > Still, in some circumstances, the current state of grep's > > gnulib-tests/Makefile.am forces errors for warnings > > What circumstances are these?
As detailed in <https://lists.gnu.org/archive/html/bug-gnulib/2025-09/msg00033.html>: $ ./configure --enable-gcc-warnings $ make CFLAGS='-g -O2' V=1 > For grep we don't recommend > --enable-gcc-warnings unless you know what you're doing. Still, --enable-gcc-warnings is enabled by default, in certain situations, through grep/configure.ac lines 107..111. I won't argue about that; that's entirely your choice which GCC warnings to apply to your package. I won't argue about "make CFLAGS='-g -O2'" either; that's part of the freedom that a user has when building a package; see also https://www.gnu.org/software/automake/manual/html_node/User-Variables.html What I'm opposed to is that these users then get a failing build, with an "error" claimed by gcc or clang, and report it as a gnulib "bug", just like it happened two days ago <https://lists.gnu.org/archive/html/bug-gnulib/2025-09/msg00018.html> and numerous times before. > In the past I've preferred stricter warnings even for Gnulib, to help > maintain the Gnulib stuff that I maintain. That's OK because this happens on the bug-gnulib mailing list, and because you are listening when I happen to say "this warning option is silly, I don't want to hear about this type of warning in code that I maintain. Whereas the grep/gnulib-tests/Makefile.am is doing a different thing: here the grep maintainer chooses warning options for code in gnulib/tests/ (including code that they don't maintain) and adds '-Werror', thereby triggering "bug" reports to bug-gnulib. My proposed patch has the purpose to stop this. I respect the warning options the grep maintainer chooses for code that they maintain; and I want the grep maintainer to respect the warning options that I choose for code that I maintain. Bruno
