Help needed with maintainer-mode
Hi! Sorry for cross-posting, but I'm not sure the rules/guidelines are the same in gcc vs binutils/gdb. TL;DR: are there some guidelines about how to use/enable maintainer-mode? In the context of the Linaro CI, I've been looking at enabling maintainer-mode at configure time in our configurations where we test patches before they are committed (aka "precommit CI", which relies on patchwork). Indeed, auto-generated files are not part of patch submissions, and when a patch implies regenerating some files before building, we currently report wrong failures because we don't perform such updates. I hoped improving this would be as simple as adding --enable-maintainer-mode when configuring, after making sure autoconf-2.69 and automake-1.15.1 were in the PATH (using our host's libtool and gettext seems OK). However, doing so triggered several problems, which look like race conditions in the build system (we build at -j160): - random build errors in binutils / gdb with messages like "No rule to make target 'po/BLD-POTFILES.in". I managed to reproduce something similar manually once, I noticed an empty Makefile; the build logs are of course difficult to read, so I couldn't figure out yet what could cause this. - random build failures in gcc in fixincludes. I think this is a race condition because fixincludes is updated concurrently both from /fixincludes and $buillddir/fixincludes. Probably fixable in gcc Makefiles. - I've seen other errors when building gcc like configure.ac:25: error: possibly undefined macro: AM_ENABLE_MULTILIB from libquadmath. I haven't investigated this yet. I've read binutils' README-maintainer-mode, which contains a warning about distclean, but we don't use this: we start our builds from a scratch directory. So... I'm wondering if there are some "official" guidelines about how to regenerate files, and/or use maintainer-mode? Maybe I missed a "magic" make target (eg 'make autoreconf-all') that should be executed after configure and before 'make all'? I've noticed that sourceware's buildbot has a small script "autoregen.py" which does not use the project's build system, but rather calls aclocal/autoheader/automake/autoconf in an ad-hoc way. Should we replicate that? Thanks, Christophe
Re: Help needed with maintainer-mode
On 29/02/2024 10:22, Christophe Lyon via Gcc wrote: > Hi! > > Sorry for cross-posting, but I'm not sure the rules/guidelines are the > same in gcc vs binutils/gdb. > > TL;DR: are there some guidelines about how to use/enable maintainer-mode? > > In the context of the Linaro CI, I've been looking at enabling > maintainer-mode at configure time in our configurations where we test > patches before they are committed (aka "precommit CI", which relies on > patchwork). > > Indeed, auto-generated files are not part of patch submissions, and > when a patch implies regenerating some files before building, we > currently report wrong failures because we don't perform such updates. > > I hoped improving this would be as simple as adding > --enable-maintainer-mode when configuring, after making sure > autoconf-2.69 and automake-1.15.1 were in the PATH (using our host's > libtool and gettext seems OK). > > However, doing so triggered several problems, which look like race > conditions in the build system (we build at -j160): > - random build errors in binutils / gdb with messages like "No rule to > make target 'po/BLD-POTFILES.in". I managed to reproduce something > similar manually once, I noticed an empty Makefile; the build logs are > of course difficult to read, so I couldn't figure out yet what could > cause this. > > - random build failures in gcc in fixincludes. I think this is a race > condition because fixincludes is updated concurrently both from > /fixincludes and $buillddir/fixincludes. Probably fixable in gcc > Makefiles. > > - I've seen other errors when building gcc like > configure.ac:25: error: possibly undefined macro: AM_ENABLE_MULTILIB > from libquadmath. I haven't investigated this yet. > > I've read binutils' README-maintainer-mode, which contains a warning > about distclean, but we don't use this: we start our builds from a > scratch directory. > > So... I'm wondering if there are some "official" guidelines about how > to regenerate files, and/or use maintainer-mode? Maybe I missed a > "magic" make target (eg 'make autoreconf-all') that should be executed > after configure and before 'make all'? > > I've noticed that sourceware's buildbot has a small script > "autoregen.py" which does not use the project's build system, but > rather calls aclocal/autoheader/automake/autoconf in an ad-hoc way. > Should we replicate that? > > Thanks, > > Christophe There are other potential gotchas as well, such as the manual copying of the generated tm.texi back into the source repo due to relicensing. Perhaps we haven't encountered that one because patches generally contain that duplicated output. If we want a CI to work reliably, then perhaps we should reconsider our policy of stripping out regenerated code. We have a number of developer practices, such as replying to an existing patch with an updated version that the CI can't handle easily (especially if the patch is part of a series), so there may be space for a discussion on how to work smarter. My calendar says we have a toolchain office hours meeting today, perhaps this would be worth bringing up. R.
Re: Help needed with maintainer-mode
Hi Christophe, On Thu, Feb 29, 2024 at 11:22:33AM +0100, Christophe Lyon via Gcc wrote: > I've noticed that sourceware's buildbot has a small script > "autoregen.py" which does not use the project's build system, but > rather calls aclocal/autoheader/automake/autoconf in an ad-hoc way. > Should we replicate that? That python script works across gcc/binutils/gdb: https://sourceware.org/cgit/builder/tree/builder/containers/autoregen.py It is installed into a container file that has the exact autoconf and automake version needed to regenerate the autotool files: https://sourceware.org/cgit/builder/tree/builder/containers/Containerfile-autotools And it was indeed done this way because that way the files are regenerated in a reproducible way. Which wasn't the case when using --enable-maintainer-mode (and autoreconfig also doesn't work). It is run on all commits and warns if it detects a change in the (checked in) generated files. https://builder.sourceware.org/buildbot/#/builders/gcc-autoregen https://builder.sourceware.org/buildbot/#/builders/binutils-gdb-autoregen Cheers, Mark
Re: Help needed with maintainer-mode
On Thu, 29 Feb 2024 at 11:41, Richard Earnshaw (lists) wrote: > > On 29/02/2024 10:22, Christophe Lyon via Gcc wrote: > > Hi! > > > > Sorry for cross-posting, but I'm not sure the rules/guidelines are the > > same in gcc vs binutils/gdb. > > > > TL;DR: are there some guidelines about how to use/enable maintainer-mode? > > > > In the context of the Linaro CI, I've been looking at enabling > > maintainer-mode at configure time in our configurations where we test > > patches before they are committed (aka "precommit CI", which relies on > > patchwork). > > > > Indeed, auto-generated files are not part of patch submissions, and > > when a patch implies regenerating some files before building, we > > currently report wrong failures because we don't perform such updates. > > > > I hoped improving this would be as simple as adding > > --enable-maintainer-mode when configuring, after making sure > > autoconf-2.69 and automake-1.15.1 were in the PATH (using our host's > > libtool and gettext seems OK). > > > > However, doing so triggered several problems, which look like race > > conditions in the build system (we build at -j160): > > - random build errors in binutils / gdb with messages like "No rule to > > make target 'po/BLD-POTFILES.in". I managed to reproduce something > > similar manually once, I noticed an empty Makefile; the build logs are > > of course difficult to read, so I couldn't figure out yet what could > > cause this. > > > > - random build failures in gcc in fixincludes. I think this is a race > > condition because fixincludes is updated concurrently both from > > /fixincludes and $buillddir/fixincludes. Probably fixable in gcc > > Makefiles. > > > > - I've seen other errors when building gcc like > > configure.ac:25: error: possibly undefined macro: AM_ENABLE_MULTILIB > > from libquadmath. I haven't investigated this yet. > > > > I've read binutils' README-maintainer-mode, which contains a warning > > about distclean, but we don't use this: we start our builds from a > > scratch directory. > > > > So... I'm wondering if there are some "official" guidelines about how > > to regenerate files, and/or use maintainer-mode? Maybe I missed a > > "magic" make target (eg 'make autoreconf-all') that should be executed > > after configure and before 'make all'? > > > > I've noticed that sourceware's buildbot has a small script > > "autoregen.py" which does not use the project's build system, but > > rather calls aclocal/autoheader/automake/autoconf in an ad-hoc way. > > Should we replicate that? > > > > Thanks, > > > > Christophe > > There are other potential gotchas as well, such as the manual copying of the > generated tm.texi back into the source repo due to relicensing. Perhaps we > haven't encountered that one because patches generally contain that > duplicated output. > It did happen a few weeks ago, with a patch that was updating the target hooks IIRC. > If we want a CI to work reliably, then perhaps we should reconsider our > policy of stripping out regenerated code. We have a number of developer > practices, such as replying to an existing patch with an updated version that > the CI can't handle easily (especially if the patch is part of a series), so > there may be space for a discussion on how to work smarter. > Sure, there are many things we can improve in the current workflow to make it more CI friendly ;-) But I was only asking how maintainer-mode is supposed to be used, so that I can replicate the process in CI. I couldn't find any documentation :-) Thanks, Christophe > My calendar says we have a toolchain office hours meeting today, perhaps this > would be worth bringing up. > > R. >
Re: Help needed with maintainer-mode
On Thu, 29 Feb 2024 at 12:00, Mark Wielaard wrote: > > Hi Christophe, > > On Thu, Feb 29, 2024 at 11:22:33AM +0100, Christophe Lyon via Gcc wrote: > > I've noticed that sourceware's buildbot has a small script > > "autoregen.py" which does not use the project's build system, but > > rather calls aclocal/autoheader/automake/autoconf in an ad-hoc way. > > Should we replicate that? > > That python script works across gcc/binutils/gdb: > https://sourceware.org/cgit/builder/tree/builder/containers/autoregen.py > > It is installed into a container file that has the exact autoconf and > automake version needed to regenerate the autotool files: > https://sourceware.org/cgit/builder/tree/builder/containers/Containerfile-autotools > > And it was indeed done this way because that way the files are > regenerated in a reproducible way. Which wasn't the case when using > --enable-maintainer-mode (and autoreconfig also doesn't work). I see. So it is possibly incomplete, in the sense that it may lack some of the steps that maintainer-mode would perform? For instance, gas for aarch64 has some *opcodes*.c files that need regenerating before committing. The regeneration step is enabled in maintainer-mode, so I guess the autoregen bots on Sourceware would miss a problem with these files? Thanks, Christophe > > It is run on all commits and warns if it detects a change in the > (checked in) generated files. > https://builder.sourceware.org/buildbot/#/builders/gcc-autoregen > https://builder.sourceware.org/buildbot/#/builders/binutils-gdb-autoregen > > Cheers, > > Mark
Re: Help needed with maintainer-mode
Hello, Christophe Lyon writes: > I hoped improving this would be as simple as adding > --enable-maintainer-mode when configuring, after making sure > autoconf-2.69 and automake-1.15.1 were in the PATH (using our host's > libtool and gettext seems OK). > > However, doing so triggered several problems, which look like race > conditions in the build system (we build at -j160): > - random build errors in binutils / gdb with messages like "No rule to > make target 'po/BLD-POTFILES.in". I managed to reproduce something > similar manually once, I noticed an empty Makefile; the build logs are > of course difficult to read, so I couldn't figure out yet what could > cause this. > > - random build failures in gcc in fixincludes. I think this is a race > condition because fixincludes is updated concurrently both from > /fixincludes and $buillddir/fixincludes. Probably fixable in gcc > Makefiles. > > - I've seen other errors when building gcc like > configure.ac:25: error: possibly undefined macro: AM_ENABLE_MULTILIB > from libquadmath. I haven't investigated this yet. I don't know about the last one, but regarding the race conditions, one workaround might be to define a make target that regenerates all files (if one doesn't exist already, I don't know) and make the CI call it with -j1 to avoid concurrency, and then do the regular build step with -j160. -- Thiago
gcc-11-20240229 is now available
Snapshot gcc-11-20240229 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20240229/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-11 revision aed43e771cdd43536c48098582f17af322bb8c3d You'll find: gcc-11-20240229.tar.xz Complete GCC SHA256=8b43944b869ba7bc6fb7ac60d3f19ddda36ef0865c0839fc568ff807e2b8ecb5 SHA1=aa96383d687b95cc5fb4d122974d18a464cfa8e8 Diffs from 11-20240222 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-11 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
