public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: Martin Jambor <mjambor@suse.cz>
Cc: GCC Mailing List <gcc@gcc.gnu.org>,
	Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org>,
	binutils@sourceware.org, gdb@sourceware.org
Subject: Re: Checks that autotools generated files were re-generated correctly
Date: Wed, 15 Nov 2023 20:48:03 +0100	[thread overview]
Message-ID: <20231115194803.GW31613@gnu.wildebeest.org> (raw)
In-Reply-To: <20231108233059.GA31613@gnu.wildebeest.org>

Hi! (adding gdb and binutils to the CC)

On Thu, Nov 09, 2023 at 12:30:59AM +0100, Mark Wielaard wrote:
> On Mon, Nov 06, 2023 at 06:04:48PM +0100, Martin Jambor wrote:
> > I have inherited Martin Liška's buildbot script that checks that all
> > sorts of autotools generated files, mainly configure scripts, were
> > re-generated correctly when appropriate.  While the checks are hopefully
> > useful, they report issues surprisingly often and reporting them feels
> > especially unproductive.
> 
> Cool! A small python script cannot replace him of course. But it is
> nice to get a small virtual mliska :)
> 
> > Could such checks be added to our server side push hooks so that commits
> > introducing these breakages would get refused automatically.  While the
> > check might be a bit expensive, it only needs to be run on files
> > touching the generated files and/or the files these are generated from.
> 
> So this doesn't just need that script, but also an execution
> environment that contains the right versions of the autotools. We
> could install those of course, but running them from a git hook on
> checkin indeed seems a little expensive.
> 
> Creating a container with the script and the right versions of all
> tools might be the best thing. Then the script can be run from a cron
> job or buildbot. Or even by someone hacking on the build/configure
> scripts to make sure they are generating with the right tools.
> 
> builder.sourceware.org already contains various of such containers:
> https://sourceware.org/cgit/builder/tree/builder/containers
> https://sourceware.org/cgit/builder/tree/README_containers
> 
> Friday is Sourceware Open Office hour (#overseers on irc.libera.chat
> at 18:00 UTC). We could hack something together then and see how to
> hook it up.

So we did indeed discuss and hack something together.

The container file is here:
https://sourceware.org/cgit/builder/tree/builder/containers/Containerfile-autotools

The script is here:
https://sourceware.org/cgit/builder/tree/builder/containers/autoregen.py

A buildbot can then use that container to run that script and then
check that git diff is empty on every commit to binutils-gdb.git and
gcc.git. If it finds an issue it will sent email with the diff.

It already found issues in both gcc and binutils-gdb. All fixed now.

Thanks to Arsen and Sam for testing, fixing and updating the script
(it now also runs aclocal).

If you want to run this locally you can use the container file to
create an image and then run autoregen.py on your local tree by bind
mounting your git tree inside it.

$ git clone https://sourceware.org/git/builder.git
$ cd builder/
$ podman build -t autotools -f builder/containers/Containerfile-autotools \
  builder/containers
$ cd .. # assuming your binutils-gdb directory is here
$ podman run --privileged -u root -v $(pwd)/binutils-gdb:/binutils-gdb \
  -ti --entrypoint "/bin/bash" autotools
# then inside the container
 cd /binutils-gdb
 autoregen.py

Change binutils-gdb to gcc if you are working on gcc.
You should also be able to do the above with docker instead of podman.

Cheers,

Mark

  reply	other threads:[~2023-11-15 19:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-06 17:04 Martin Jambor
2023-11-07 22:13 ` Frank Ch. Eigler
2023-11-08 23:30 ` Mark Wielaard
2023-11-15 19:48   ` Mark Wielaard [this message]
2023-11-16 18:37     ` Martin Jambor
     [not found] <65491cda.c80a0220.5fa79.7688SMTPIN_ADDED_BROKEN@mx.google.com>
2023-11-06 17:19 ` Christophe Lyon
2023-11-07  7:38   ` Maxim Kuvyrkov
2023-11-07 13:50     ` Carlos O'Donell
2023-11-07 14:36     ` Martin Jambor
     [not found]     ` <654a4b60.2e0a0220.7f3b.6e5aSMTPIN_ADDED_BROKEN@mx.google.com>
2023-11-07 15:42       ` Christophe Lyon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231115194803.GW31613@gnu.wildebeest.org \
    --to=mark@klomp.org \
    --cc=binutils@sourceware.org \
    --cc=gcc@gcc.gnu.org \
    --cc=gdb@sourceware.org \
    --cc=maxim.kuvyrkov@linaro.org \
    --cc=mjambor@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).