On Mon, 4 Mar 2024 at 12:25, Jonathan Wakely <jwakely....@gmail.com> wrote:
>
> 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
>
This script touches files such that they appear more recent than their
dependencies,
so IIUC even if one uses --enable-maintainer-mode, it will have no effect.
For auto* files, this is "fine" as we can run autoreconf or
autoregen.py before starting configure+build, but what about other
files?
For instance, if we have to test a patch which implies changes to
fixincludes/fixincl.x, how should we proceed?
1- git checkout (with possibly "wrong" timestamps)
2- apply patch-to-test
3- contrib/gcc_update -t
4- configure --enable-maintainer-mode
I guess --enable-maintainer-mode would be largely (if not completely)
disabled by step 3 above?
And we should probably swap steps 2 and 3, so that the effects of
patch-to-test are handled by make?
Thanks,
Christophe
>
>
> >
> > 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
