On Mon, 4 Mar 2024 at 10:44, Christophe Lyon via Gcc <gcc@gcc.gnu.org> wrote: > > Hi! > > On Mon, 4 Mar 2024 at 10:36, Thomas Schwinge <tschwi...@baylibre.com> wrote: > > > > Hi! > > > > On 2024-03-04T00:30:05+0000, Sam James <s...@gentoo.org> wrote: > > > Mark Wielaard <m...@klomp.org> writes: > > >> On Fri, Mar 01, 2024 at 05:32:15PM +0100, Christophe Lyon wrote: > > >>> [...], I read > > >>> https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration > > >>> which basically says "run autoreconf in every dir where there is a > > >>> configure script" > > >>> but this is not exactly what autoregen.py is doing. IIRC it is based > > >>> on a script from Martin Liska, do you know/remember why it follows a > > >>> different process? > > >> > > >> CCing Sam and Arsen who helped refine the autoregen.py script, who > > >> might remember more details. We wanted a script that worked for both > > >> gcc and binutils-gdb. And as far as I know autoreconf simply didn't > > >> work in all directories. We also needed to skip some directories that > > >> did contain a configure script, but that were imported (gotools, > > >> readline, minizip). > > > > > > What we really need to do is, for a start, land tschwinge/aoliva's > > > patches [0] > > > for AC_CONFIG_SUBDIRS. > > > > Let me allocate some time this week to get that one completed. > > > > > Right now, the current situation is janky and it's nowhere near > > > idiomatic autotools usage. It is not a comfortable experience > > > interacting with it even as someone who is familiar and happy with using > > > autotools otherwise. > > > > > > I didn't yet play with maintainer-mode myself but I also didn't see much > > > point given I knew of more fundamental problems like this. > > > > > > [0] > > > https://inbox.sourceware.org/gcc-patches/oril72c4yh....@lxoliva.fsfla.org/ > > > > Thanks for the background. I didn't follow that discussion at that time :-) > > So... I was confused because I noticed many warnings when doing a simple > find . -name configure |while read f; do echo $f;d=$(dirname $f) && > autoreconf -f $d && echo $d; done > as suggested by https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration > > Then I tried with autoregen.py, and saw the same.... and now just > checked Sourceware's bot logs and saw the same numerous warnings at > least in GCC (didn't check binutils yet). Looks like this is > "expected" .... > > I started looking at auto-regenerating these files in our CI a couple > of weeks ago, after we received several "complaints" from contributors > saying that our precommit CI was useless / bothering since it didn't > regenerate files, leading to false alarms. > But now I'm wondering how such contributors regenerate the files > impacted by their patches before committing, they probably just > regenerate things in their subdir of interest, not noticing the whole > picture :-( > > As a first step, we can probably use autoregen.py too, and declare > maintainer-mode broken. However, I do notice that besides the rules > about regenerating configure/Makefile.in/..., maintainer-mode is also > used to update some files. > In gcc: > fixincludes: fixincl.x > libffi: doc/version.texi > libgfortran: some stuff :-) > libiberty: functions.texi
My recently proposed patch adds the first of those to gcc_update, the other should be done too. https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647027.html > > in binutils/bfd: > gdb/sim > bfd/po/SRC-POTFILES.in > bfd/po/BLD-POTFILES.in > bfd/bfd-in2.h > bfd/libbfd.h > bfd/libcoff.h > binutils/po/POTFILES.in > gas/po/POTFILES.in > opcodes/i386*.h > gdb/copying.c > gdb/data-directory/*.xml > gold/po/POTFILES.in > gprof/po/POTFILES.in > gfprofng/doc/version.texi > ld/po/SRC-POTFILES.in > ld/po/BLD-POTFILES.in > ld: ldgram/ldlex... and all emulation sources > libiberty/functions.texi > opcodes/po/POTFILES.in > opcodes/aarch64-{asm,dis,opc}-2.c > opcodes/ia64 msp430 rl78 rx z8k decoders > > How are these files "normally" expected to be updated? Do people just > manually uncomment the corresponding maintainer lines in the Makefiles > and update manually? In particular we hit issues several times with > files under opcodes, that we don't regenerate currently. Maybe we > could build binutils in maintainer-mode at -j1 but, well.... > > README-maintainer-mode in binutils/gdb only mentions a problem with > 'make distclean' and maintainer mode > binutils/README-how-to-make-a-release indicates to use > --enable-maintainer-mode, and the sample 'make' invocations do not > include any -j flag, is that an indication that only -j1 is supposed > to work? > Similarly, the src-release.sh script does not use -j. > > Thanks, > > Christophe > > > > > Grüße > > Thomas
