On Wed, 3 Apr 2024 at 09:46, Jakub Jelinek via Gcc <gcc@gcc.gnu.org> wrote: > > On Wed, Apr 03, 2024 at 10:22:24AM +0200, Christophe Lyon wrote: > > Any concerns/objections? > > I'm all for it, in fact I've been sending it like that myself for years > even when the policy said not to. In most cases, the diff for the > regenerated files is very small and it helps even in patch review to > actually check if the configure.ac/m4 etc. changes result just in the > expected changes and not some unrelated ones (e.g. caused by user using > wrong version of autoconf/automake etc.). > There can be exceptions, e.g. when in GCC we update from a new version > of Unicode, the regenerated ucnid.h diff can be large and > uname2c.h can be huge, such that it can trigger the mailing list size > limits even when the patch is compressed, see e.g. > https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636427.html > https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636426.html > But I think most configure or Makefile changes should be pretty small, > usual changes shouldn't rewrite everything in those files.
For libstdc++ we've had two "large" changes to regenerated files in the past year, but they're not common: https://gcc.gnu.org/r14-5424-gdb50aea6259545 https://gcc.gnu.org/r14-5342-g898fd81b831c10 We were getting large, useless diffs for libstdc++-v3/include/bits/version.h too (e.g. r14-7220-gac1a399bf61b04) but I've fixed that now. In ye olde days I used filterdiff to strip the generated files from patch submissions, but with git send-email I no longer use filterdiff, so as Christophe said, the suggested policy would avoid manually editing emails before sending. I don't feel strongly either way, but I have no objection to the change.
