From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 8A9E73858D33; Mon, 4 Mar 2024 15:36:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8A9E73858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 8A9E73858D33 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709566584; cv=none; b=kuZXR84WzqyVNdqaEazzmrG8p3wnbcExIFn9re+0tuE1cI2GBPmWJdoj26dKU4p8gzWTFKHE3un9NlS3ZVv0a6/zp+3i+1W6zGKm1r2VpiLaWib0BSftizIcSyLup33cOuMqSdHbWRUl1FDcz014bLX+3KD+j4emaP4w6MH/zHo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709566584; c=relaxed/simple; bh=DJg4cYA2RE8aTX2Gs0OxVmh9pUGHQXOlAgRBn4x7+O0=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=xFnAzpbI2HqPBRJml+3N3EyhT/QK1cWJp8E4+I7Zk/Nn8cSXqVD1TVZDTPceP+ouzNj9ObZjCFhoqWxEnXCveW7AZTjSkQYGh25OT/yXfJvfC9hIxEnsdx0cXXwC26HLeK7UXKH6wlF39X7ArhHa+o3eVMdd3HKHZKcP2yprjiA= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id AFE8D1FB; Mon, 4 Mar 2024 07:36:57 -0800 (PST) Received: from [10.2.78.54] (e120077-lin.cambridge.arm.com [10.2.78.54]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6E6F73F73F; Mon, 4 Mar 2024 07:36:19 -0800 (PST) Message-ID: Date: Mon, 4 Mar 2024 15:36:18 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Help needed with maintainer-mode Content-Language: en-GB To: Christophe Lyon , Jonathan Wakely Cc: Thomas Schwinge , Sam James , Mark Wielaard , binutils@sourceware.org, gcc@gcc.gnu.org, gdb-patches@sourceware.org, David Malcolm , arsen@gentoo.org, Alexandre Oliva References: <20240229110039.GB18580@gnu.wildebeest.org> <72dff8ae4cc6b56208b7e7f93676debcaba900d4.camel@klomp.org> <20240303211541.GK13156@gnu.wildebeest.org> <87v862260i.fsf@gentoo.org> <87le6y7303.fsf@euler.schwinge.ddns.net> From: "Richard Earnshaw (lists)" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3491.6 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,SPF_HELO_NONE,SPF_NONE,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: On 04/03/2024 14:46, Christophe Lyon via Gcc wrote: > On Mon, 4 Mar 2024 at 12:25, Jonathan Wakely wrote: >> >> On Mon, 4 Mar 2024 at 10:44, Christophe Lyon via Gcc wrote: >>> >>> Hi! >>> >>> On Mon, 4 Mar 2024 at 10:36, Thomas Schwinge wrote: >>>> >>>> Hi! >>>> >>>> On 2024-03-04T00:30:05+0000, Sam James wrote: >>>>> Mark Wielaard writes: >>>>>> On Fri, Mar 01, 2024 at 05:32:15PM +0100, Christophe Lyon wrote: >>>>>>> [...], I read >>>>>>> https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration >>>>>>> which basically says "run autoreconf in every dir where there is a >>>>>>> configure script" >>>>>>> but this is not exactly what autoregen.py is doing. IIRC it is based >>>>>>> on a script from Martin Liska, do you know/remember why it follows a >>>>>>> different process? >>>>>> >>>>>> CCing Sam and Arsen who helped refine the autoregen.py script, who >>>>>> might remember more details. We wanted a script that worked for both >>>>>> gcc and binutils-gdb. And as far as I know autoreconf simply didn't >>>>>> work in all directories. We also needed to skip some directories that >>>>>> did contain a configure script, but that were imported (gotools, >>>>>> readline, minizip). >>>>> >>>>> What we really need to do is, for a start, land tschwinge/aoliva's patches [0] >>>>> for AC_CONFIG_SUBDIRS. >>>> >>>> Let me allocate some time this week to get that one completed. >>>> >>>>> Right now, the current situation is janky and it's nowhere near >>>>> idiomatic autotools usage. It is not a comfortable experience >>>>> interacting with it even as someone who is familiar and happy with using >>>>> autotools otherwise. >>>>> >>>>> I didn't yet play with maintainer-mode myself but I also didn't see much >>>>> point given I knew of more fundamental problems like this. >>>>> >>>>> [0] https://inbox.sourceware.org/gcc-patches/oril72c4yh.fsf@lxoliva.fsfla.org/ >>>> >>> >>> Thanks for the background. I didn't follow that discussion at that time :-) >>> >>> So... I was confused because I noticed many warnings when doing a simple >>> find . -name configure |while read f; do echo $f;d=$(dirname $f) && >>> autoreconf -f $d && echo $d; done >>> as suggested by https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration >>> >>> Then I tried with autoregen.py, and saw the same.... and now just >>> checked Sourceware's bot logs and saw the same numerous warnings at >>> least in GCC (didn't check binutils yet). Looks like this is >>> "expected" .... >>> >>> I started looking at auto-regenerating these files in our CI a couple >>> of weeks ago, after we received several "complaints" from contributors >>> saying that our precommit CI was useless / bothering since it didn't >>> regenerate files, leading to false alarms. >>> But now I'm wondering how such contributors regenerate the files >>> impacted by their patches before committing, they probably just >>> regenerate things in their subdir of interest, not noticing the whole >>> picture :-( >>> >>> As a first step, we can probably use autoregen.py too, and declare >>> maintainer-mode broken. However, I do notice that besides the rules >>> about regenerating configure/Makefile.in/..., maintainer-mode is also >>> used to update some files. >>> In gcc: >>> fixincludes: fixincl.x >>> libffi: doc/version.texi >>> libgfortran: some stuff :-) >>> libiberty: functions.texi >> >> My recently proposed patch adds the first of those to gcc_update, the >> other should be done too. >> https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647027.html >> > > This script touches files such that they appear more recent than their > dependencies, > so IIUC even if one uses --enable-maintainer-mode, it will have no effect. > For auto* files, this is "fine" as we can run autoreconf or > autoregen.py before starting configure+build, but what about other > files? > For instance, if we have to test a patch which implies changes to > fixincludes/fixincl.x, how should we proceed? > 1- git checkout (with possibly "wrong" timestamps) > 2- apply patch-to-test > 3- contrib/gcc_update -t > 4- configure --enable-maintainer-mode If you ran git reset --hard master // restore state to 'master' contrib/gcc_update // pull latest code then anything coming from upstream will be touched automatically. You really don't want to re-touch the files after patching unless you're sure they've all been patched correctly, it will break if there's anything regenerated that's missing. R. > > I guess --enable-maintainer-mode would be largely (if not completely) > disabled by step 3 above? > And we should probably swap steps 2 and 3, so that the effects of > patch-to-test are handled by make? > > Thanks, > > Christophe > >> >> >>> >>> in binutils/bfd: >>> gdb/sim >>> bfd/po/SRC-POTFILES.in >>> bfd/po/BLD-POTFILES.in >>> bfd/bfd-in2.h >>> bfd/libbfd.h >>> bfd/libcoff.h >>> binutils/po/POTFILES.in >>> gas/po/POTFILES.in >>> opcodes/i386*.h >>> gdb/copying.c >>> gdb/data-directory/*.xml >>> gold/po/POTFILES.in >>> gprof/po/POTFILES.in >>> gfprofng/doc/version.texi >>> ld/po/SRC-POTFILES.in >>> ld/po/BLD-POTFILES.in >>> ld: ldgram/ldlex... and all emulation sources >>> libiberty/functions.texi >>> opcodes/po/POTFILES.in >>> opcodes/aarch64-{asm,dis,opc}-2.c >>> opcodes/ia64 msp430 rl78 rx z8k decoders >>> >>> How are these files "normally" expected to be updated? Do people just >>> manually uncomment the corresponding maintainer lines in the Makefiles >>> and update manually? In particular we hit issues several times with >>> files under opcodes, that we don't regenerate currently. Maybe we >>> could build binutils in maintainer-mode at -j1 but, well.... >>> >>> README-maintainer-mode in binutils/gdb only mentions a problem with >>> 'make distclean' and maintainer mode >>> binutils/README-how-to-make-a-release indicates to use >>> --enable-maintainer-mode, and the sample 'make' invocations do not >>> include any -j flag, is that an indication that only -j1 is supposed >>> to work? >>> Similarly, the src-release.sh script does not use -j. >>> >>> Thanks, >>> >>> Christophe >>> >>>> >>>> Grüße >>>> Thomas