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 6D31E3858C60; Thu, 14 Mar 2024 18:10:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6D31E3858C60 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 6D31E3858C60 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=1710439846; cv=none; b=B1+2jbxx5n/gi1ONCHY4HQgcF/v/OF+uoBnwt5Nguazq25Mbp+qLmUYzBPvyEpDxM14xxv0+l9e8JSBtLCIE2XheeLyoixsKCSY4sKYErjjQS7SaaQCxhRIo+qRqeQN1Ed/FNlepEzKnj0oAg2j1wg2vbSrzCNG8KC/2cdxjUBQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710439846; c=relaxed/simple; bh=Dg0EJvECjvcxnW3C4UQ14Ai+p8M9Ts47UjVOGkp6Yzc=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=XT8tuMcGp0Ff+iUJzOrsu6FmnEQKXyUu+BLEN42962+76zkBwaqL2eDgrTQ9cNch1wwmIjiJFhSCVFXNjrjplb2yHll86KdxhRvyPKuAC8bPM9y7r8Rh1iLvF3Z/sGM5qZbYYGn9fIqSXBr5aXnh8Y/3tnNfH4TCY5cmOxtFZps= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1710439842; bh=Dg0EJvECjvcxnW3C4UQ14Ai+p8M9Ts47UjVOGkp6Yzc=; h=Date:Subject:To:References:From:In-Reply-To:From; b=P3ESprtcQJwVUXPz6Wfoj2KWMG5j+M90ZsLos+vdFYa4mUgmIibwxA7kSbBdFwO1o neB4jQaJ9HYxRzZ45Qa/KVEPyUAJ6ff98XW+UUxmHgqXDw671M7zHiJswXQeXr7JS8 0hqp9+I5+lUZ3xra3P6ucN+OuPLqQ1DcoOA3FlTk= 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 153A81E01D; Thu, 14 Mar 2024 14:10:41 -0400 (EDT) Message-ID: <1eb529f2-3842-4090-a8e2-f713a28f2394@simark.ca> Date: Thu, 14 Mar 2024 14:10:41 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] add regenerate Makefile target Content-Language: en-US To: Christophe Lyon , binutils@sourceware.org, gdb@sourceware.org, gcc@gcc.gnu.org References: <20240313080237.1143034-1-christophe.lyon@linaro.org> From: Simon Marchi In-Reply-To: <20240313080237.1143034-1-christophe.lyon@linaro.org> 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,T_SCC_BODY_TEXT_LINE 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-03-13 04:02, Christophe Lyon via Gdb wrote: > Hi! > > After recent discussions on IRC and on the lists about maintainer-mode > and various problems with auto-generated source files, I've written > this small prototype. > > Based on those discussions, I assumed that people generally want to > update autotools files using a script similar to autoregen.py, which > takes care of running aclocal, autoheader, automake and autoconf as > appropriate. > > What is currently missing is a "simple" way of regenerating other > files, which happens normally with --enable-maintainer-mode (which is > reportedly broken). This patch as a "regenerate" Makefile target > which can be called to update those files, provided > --enable-maintainer-mode is used. > > I tried this approach with the following workflow for binutils/gdb: > - run autoregen.py in srcdir > - cd builddir > - configure --enable-maintainer-mode > - make all-bfd all-libiberty regenerate -j1 > - for gdb: make all -C gdb/data-directory -j1 > - make all -jXXX > > Making 'all' in bfd and libiberty is needed by some XXX-gen host > programs in opcodes. > > The advantage (for instance for CI) is that we can regenerate files at > -j1, thus avoiding the existing race conditions, and build the rest > with -j XXX. > > Among drawbacks: > - most sub-components use Makefile.am, but gdb does not: this may make > maintenance more complex (different rules for different projects) > - maintaining such ad-hoc "regenerate" rules would require special > attention from maintainers/reviewers > - dependency on -all-bfd and all-libiberty is probably not fully > intuitive, but should not be a problem if the "regenerate" rules > are used after a full build for instance > > Of course Makefile.def/Makefile.tpl would need further cleanup as I > didn't try to take gcc into account is this patch. > > Thoughts? My first thought it: why is it a Makefile target, instead of some script on the side (like autoregen.sh). It would be nice / useful to be able to it without configuring / building anything. For instance, the autoregen buildbot job could run it without configuring anything. Ideally, the buildbot wouldn't maintain its own autoregen.py file on the side, it would just use whatever is in the repo. Looking at the rule to re-generate copying.c in gdb for instance: # Make copying.c from COPYING $(srcdir)/copying.c: @MAINTAINER_MODE_TRUE@ $(srcdir)/../COPYING3 $(srcdir)/copying.awk awk -f $(srcdir)/copying.awk \ < $(srcdir)/../COPYING3 > $(srcdir)/copying.tmp mv $(srcdir)/copying.tmp $(srcdir)/copying.c There is nothing in this code that requires having configured the source tree. This code could for instance be moved to some generate-copying-c.sh script. generate-copying-c.sh could be called by an hypothetical autoregen.sh script, as well as the copying.c Makefile target, if we want to continue supporting the maintainer mode. Much like your regenerate targets, an autoregen.sh script in a given directory would be responsible to re-generate all the files in this directory that are generated and checked in git. It would also be responsible to call any autoregen.sh file in subdirectories. There's just the issue of files that are generated using tools that are compiled. When experimenting with maintainer mode the other day, I stumbled on the opcodes/i386-gen, for instance. I don't have a good solution to that, except to rewrite these tools in a scripting language like Python. Simon