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>
Subject: Re: Checks that autotools generated files were re-generated correctly
Date: Thu, 9 Nov 2023 00:30:59 +0100	[thread overview]
Message-ID: <20231108233059.GA31613@gnu.wildebeest.org> (raw)
In-Reply-To: <ri6il6e24pb.fsf@>

Hi Martin,

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.

Cheers,

Mark

  parent reply	other threads:[~2023-11-08 23:31 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 [this message]
2023-11-15 19:48   ` Mark Wielaard
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=20231108233059.GA31613@gnu.wildebeest.org \
    --to=mark@klomp.org \
    --cc=gcc@gcc.gnu.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).