From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 853543858D20 for ; Tue, 30 Apr 2024 17:59:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 853543858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 853543858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714499996; cv=none; b=sEQFCm40K5ZURckVdX9DtbJzbqH0DcFzH30Ssn/pQhQyDkJljVfFHizQb0qxKqIDATcokM6Jb/oz6zFTyqtO9IP49Mmo/MFR+2EXSiN3GNJ+9SUbJ/i7Y+bc9+YYwIFplboqIyzT3aB2ko6ukXG5iSvg/SLMmRR/AkBhG39f7Ns= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714499996; c=relaxed/simple; bh=pytqI7T8v+atO6Dx5HFnjCdy+k311g8nvduMTCgVPtY=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=cyzsbplYTMduC0kB60jDh6qP7IIPqS80rJwGrRBuR/ZZE69TalV3dZhTO6y3MY3JHQAJk5JVjlbOw6T6/wPKQ+ZJPjKheDfB5aeJIz8K4+ukoqfrd/wPrlLYzAohIKvKc3GFDog/FiNZ5Ai1Tis3U0dg4yj6hwfAV7varkqwVlk= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1714499993; bh=pytqI7T8v+atO6Dx5HFnjCdy+k311g8nvduMTCgVPtY=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=e/U5etzi1wxInJnS8zEtCdOkid7N8FdOK6uwokWqgyiyNo7p8/Aec7bQAplvyC8AG ajMnaWTbEVjpnGLy+9ED8u6oARiUDSj5Fnlpl7tqS3dAznW0Cc8MWRFGyfA4l6tYrM esQY1zDKOpasFRKyXNZQIHapWdwRk24Es1K8h1dk= Received: from [10.0.0.11] (modemcable238.237-201-24.mc.videotron.ca [24.201.237.238]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 7FFF91E092; Tue, 30 Apr 2024 13:59:53 -0400 (EDT) Message-ID: Date: Tue, 30 Apr 2024 13:59:52 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] contrib: Add autoregen.py To: Christophe Lyon , Sam James Cc: gdb@sourceware.org References: <20240419090903.2080043-1-christophe.lyon@linaro.org> <87sezh558o.fsf@gentoo.org> Content-Language: en-US From: Simon Marchi In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2024-04-30 08:50, Christophe Lyon via Gdb wrote: >> It may be nice (not sure) to include `git log` or `git shortlog` >> in the commit message to preserve some history too. >> >>> >>> It is intended as a helper to regenerate files managed by autotools >>> (autoconf, automake, aclocal, ....), as well as the toplevel >>> Makefile.in which is created by autogen. >>> >>> Other files can be updated when using maintainer-mode, but this is not >>> covered by this script. >> >> Who will own contrib/autoregen.py? Do we need to get all changes >> reviewed across gdb, binutils, and gcc? The shared files tend to be a >> huge pain for this. > Yes, that's a concern I have. > My motivation for adding it to contrib/ is to make it more visible (I > don't think > many contributors know where to find the sources of the autoregen > buildbot, maybe most don't know it exists) > It would also mean that the buildbot could do the equivalent of > cd $project #project is one of gcc, binutils-gdb > if [ -f .contrib/autoregen.py ]; then > ./contrib/autoregen.py > fi > > but that doesn't solve the maintenance pain indeed. > > Or maybe just drop this idea, and somehow make the existence > of the buildbot more widely known? (how?) Having this file in the repo is much better. This way, we know that a particular version of the script at a given commit works well for the code in the repo at that commit. This way you can go back in time at an old commit and re-generate things using the autoregen.py at that commit, and it should just work. I would suggest that maintainers on either side (gcc and binutils-gdb) can approve modifications to the script, we just need to make sure to sync the changes to the other repo now and then, just like we do for other shared files. Simon