From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id DF5913858418 for ; Sun, 10 Dec 2023 23:35:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DF5913858418 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org DF5913858418 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=45.83.234.184 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702251309; cv=none; b=Lp5tyCuUvjsjVjunxPot8K3K1ua0bGUwxYMRWEGHt7xaEXmFBAQ2HWAq2dzAYaON5R9m+hVqK2Bm4JbWmeO2xMcw48Oy3H+ZHeG1p9Cmj4Trt5xrLpNPqXFJmZeMA3wuVzxxt8O4ZWONwOEJKq09WHknw5+d73hoV38o+SjrCsk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702251309; c=relaxed/simple; bh=Waz3/KmkT6qVem0SFfmMwOSQ1XCO3JL3VeDlI9eAakA=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=vz/AboXvYsOtBBOEx+apLnGL73aCUBcvnZY0aLrx15ukNm4gvbko5bwy//eVfGyX9ZLifI8j7XXcr5+jWKL5Y+AVPdS0KRsv6f9jRP1DeBB9n1kdM39YjnUbK5ZEbi1rs1csk9DsVmOD+nWc8Wph6913IUMG/IZ8nL6WDwJI6mA= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by gnu.wildebeest.org (Postfix, from userid 1000) id 04728302FDCD; Mon, 11 Dec 2023 00:35:06 +0100 (CET) Date: Mon, 11 Dec 2023 00:35:06 +0100 From: Mark Wielaard To: David Malcolm Cc: Joseph Myers , Tobias Burnus , gcc-patches Subject: Re: [PATCH 0/4] v2 of Option handling: add documentation URLs Message-ID: <20231210233506.GC14917@gnu.wildebeest.org> References: <9e5d6710-84e-15b9-d955-5381a6dc18a9@codesourcery.com> <20231116142858.3996740-1-dmalcolm@redhat.com> <20231121010937.848E320433@pchp3.se.axis.com> <06599eb5c08f8461ec77d7f032e6968558ce1d90.camel@redhat.com> <6114f586-c61f-4695-bf3e-106b98c9fe20@codesourcery.com> <419f3147-fdb3-fcda-fcaf-23b08e2ca872@codesourcery.com> <3c6df46e0031a707eb650e8540b65c1cd7457829.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3c6df46e0031a707eb650e8540b65c1cd7457829.camel@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,KAM_SHORT,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi David, On Fri, Dec 08, 2023 at 06:35:56PM -0500, David Malcolm wrote: > On Tue, 2023-11-21 at 23:43 +0000, Joseph Myers wrote: > > On Tue, 21 Nov 2023, Tobias Burnus wrote: > > > > > On 21.11.23 14:57, David Malcolm wrote: > > > > On Tue, 2023-11-21 at 02:09 +0100, Hans-Peter Nilsson wrote: > > > > > Sorry for barging in though I did try finding the relevant > > > > > discussion, but is committing this generated stuff necessary? > > > > > Is it because we don't want to depend on Python being > > > > > present at build time? > > > > Partly, yes, [...] > > > > > > I wonder how to ensure that this remains up to date. Should there > > > be an item at > > > > > > https://gcc.gnu.org/branching.html and/or > > > https://gcc.gnu.org/releasing.html similar to the .pot generation? > > > > My suggestion earlier in the discussion was that it should be > > added to the post-commit CI discussed starting at > > (I > > think that CI is now in operation).  These are generated files > > that ought to be kept up to date with each commit that affects > > .opt files, unlike the .pot files where the expectation is that > > they should be up to date for releases and updated from time to > > time at other times for submission to the TP. > > > I had a go at scripting the testing of this, but I am terrible at shell > scripts (maybe I should use Python?). Here's what I have so far: > > $ cat contrib/regenerate-index-urls.sh > > set -x > > SRC_DIR=$1 > BUILD_DIR=$2 > NUM_JOBS=$3 > > # FIXME: error-checking! > > mkdir -p $BUILD_DIR || exit 1 > cd $BUILD_DIR > $SRC_DIR/configure --disable-bootstrap --enable-languages=c,d,fortran || exit 2 > make html-gcc -j$NUM_JOBS || exit 3 > cd gcc || exit 4 > make regenerate-opt-urls || exit 5 > cd $SRC_DIR > (git diff $1 > /dev/null ) && echo "regenerate-opt-urls needs to be run and the results committed" || exit 6 > > # e.g. > # time bash contrib/regenerate-index-urls.sh $(pwd) $(pwd)/../build-ci 64 > > This takes about 100 seconds of wallclock on my 64-core box (mostly > configuring gcc, which as well as the usual sequence of unparallelized > tests seems to require building libiberty and lto-plugin). Is that > something we want to do on every commit? Is implementing the CI a > blocker for getting the patches in? (if so, I'll likely need some help) The CI builers don't have 64-cores, but a couple of hundred seconds shouldn't be an issue to do on each commit (OSUOSL just got us a second x86_64 container builder for larger jobs). The above can easily be added to the existing gcc-autoregen builder: https://builder.sourceware.org/buildbot/#/builders/gcc-autoregen https://sourceware.org/cgit/builder/tree/builder/master.cfg#n3453 Once your patch is in please feel free to sent an email to buildbot@sourceware.org https://sourceware.org/mailman/listinfo/buildbot And we'll add the above build steps and update the autotools Containerfile to include the fortran (gfortran?) and d (gdc?) build dependencies. Cheers, Mark