From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id EyetLycC+2U/Bg8AWB0awg (envelope-from ) for ; Wed, 20 Mar 2024 11:35:03 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=urs8i/WL; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id B34311E0C0; Wed, 20 Mar 2024 11:35:03 -0400 (EDT) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 95BD61E030 for ; Wed, 20 Mar 2024 11:35:01 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2A4653858287 for ; Wed, 20 Mar 2024 15:35:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2A4653858287 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1710948901; bh=JrU6vbbndxbeSNTVxvmNp/eZ/4U1mhvPG50P2Jhgfc4=; h=Date:Subject:To:Cc:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=urs8i/WLmZiKDoXCIEn8Pjwealwf3Tm9yWlJr1r1MeYu42BIYX3wzKM91TXkhKbUu +7/hxXDz/ZXJMBIdxtmyKkbHYGKTC4pUUNMXgQpeIZ62gzTqsBn4rj7vtlHvPEk3ar rnfRoOk7Bw0gc5OwB5SJWH3brrqTZy5Gn6ZsebVY= Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id D43C13858D28; Wed, 20 Mar 2024 15:34:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D43C13858D28 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D43C13858D28 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710948860; cv=none; b=LV98jKdKXX3s9jXv7XfU1hu8P9zE3UmQL+2Q1+kZUbm4tPQcj4lCiROjwHc7rwAsKIyJ1s6z6RRzYCVviD7K8fdV8pWQbW5gL71K67M8A9crPNoHBSmPiFfm6+OJ+QvcqTGl9oOUj0zjSwF0cd5QWNjOdgrsYJ2BAWZoUuBbZ5U= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710948860; c=relaxed/simple; bh=uUjknjxUdrKXfNbXXrFPtuzKyG07qKtBQRJyUtxKc4g=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=SPSPam5ViNQ/lMytalEaMWIGfKAQH76xEJFwnxB/CrLr0enIcsApawWprMeTZ2AmfuP8BL+enxo17zVLnuroXQkYag9iOJ/OmN/L0kb/L92NO5GOYDElZer6M230YK0O5myCXAM8T+noR0qmHbsFTNTLOXRBGwcQjFh87gRxa/E= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from [172.16.0.192] (192-222-143-198.qc.cable.ebox.net [192.222.143.198]) (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 1F5931E030; Wed, 20 Mar 2024 11:34:08 -0400 (EDT) Message-ID: <33f72ef7-f990-437d-8fc4-dba08d7db24b@simark.ca> Date: Wed, 20 Mar 2024 11:34:08 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] add regenerate Makefile target Content-Language: fr To: Christophe Lyon Cc: binutils@sourceware.org, gdb@sourceware.org, gcc@gcc.gnu.org References: <20240313080237.1143034-1-christophe.lyon@linaro.org> <1eb529f2-3842-4090-a8e2-f713a28f2394@simark.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.8 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 X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Simon Marchi via Gdb Reply-To: Simon Marchi Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" On 3/18/24 13:25, Christophe Lyon wrote: > Well the rule to regenerate Makefile.in (eg in in opcodes/) is a bit > more complex > than just calling automake. IIUC it calls automake --foreign it any of > *.m4 file from $(am__configure_deps) that is newer than Makefile.in > (with an early exit in the loop), does nothing if Makefile.am or > doc/local.mk are newer than Makefile.in, and then calls 'automake > --foreign Makefile' The rules looks complex because they've been generated by automake, this Makefile.in is not written by hand. And I guess automake has put `--foreign` there because foreign is used in Makefile.am: AUTOMAKE_OPTIONS = foreign no-dist But a simple call so `automake -f` (or `autoreconf -f`) just works, as automake picks up the foreign option from AUTOMAKE_OPTIONS, so a human or an external script who wants to regenerate things would probably just use that. > The bot I want to put in place would regenerate things as they are > supposed to be, then build and run the testsuite to make sure that > what is supposed to be committed would work (if the committer > regenerates everything correctly) For your job, would it be fine to just force-regenerate everything and ignore timestamps (just like the buildbot's autoregen job wants to do)? It would waste a few cycles, but it would be much simpler. Simon