From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) by sourceware.org (Postfix) with ESMTPS id BD12D385842B for ; Mon, 4 Mar 2024 10:42:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BD12D385842B Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org BD12D385842B Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::634 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709548976; cv=none; b=QwEugvAz4eVwyDid1v+msxs6CpqBHconZf3Ug0jmSToaLUHO78tCDjU2PRTkzsbpSLq8+60CbEFY5TvRDFaBMGAirKPBkuDJUfrQy4vSTUARLSJZdS7E+ppVapit/rlWICxIPfiqV6HJrpIB1uZxkGRsJtO4qqslg4ePDL6djXQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709548976; c=relaxed/simple; bh=Tk/WRxT0AyqtArEdF3C71O9Q8IaB2Ua31uSsuM2T5Vc=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=VFTWz5+QimtzwjsPgqhQKJR/9uKW7LuQjXlKntm6ZgVV74JWR+UX3H+Me73MlJMYjGjEUEvkih8Hzl6Lb+XPI3LtU0u9057/VoEy+w+ftkXnEQ0LH/meC6REqUXcUrytnMkMroO/Ia0nE3LQ1SHMbTzeOjLGdtYlUxT0gcvdcN0= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-a450bedffdfso145481866b.3 for ; Mon, 04 Mar 2024 02:42:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1709548970; x=1710153770; darn=gcc.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=YuK76u6rjT2Me90IuIYH2v9Bhgjpm+18HjVNYEVbcpw=; b=VxIGMbb6RS0Cfuu+Z83maZ2jKF1m13AyT5z0eOPs7age93lMA4wxq0vR/7Em1UJele PsTiVE1vjVUcy8F5l78WHODipl2b2OEjc5iw4MEGlU6/pLpxBuk9QcFYLyAWhxlZO+jY zqGE+WGNKVWM9pO3WkiVPtrBJn5NOjuw5sUcSbg9w5UJmiHRCl71a/qft03kWaxftUyJ 908kAaJ4gYBnibQLYY9pPakApz7EUhSm6IBn3tyel2kwMiV2LyKvIud7Uo6o2lvMfr0G i+sakvxzh+9+LrMbgjiZ7bIP9eaEZkFu8fC1Yfr9iJxknfKG1q0UXIaPDZPw4EfDX/b6 1dVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709548970; x=1710153770; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=YuK76u6rjT2Me90IuIYH2v9Bhgjpm+18HjVNYEVbcpw=; b=Xk69tcLkd073vXC8BqTx7txGaSv5XMdsVqo3QNA/HgNIBGU9UkAjK7MwGWLCN6shRq oKZokwqEbsfoHNBXry7zOYHin9RXrl0RxnKgcXJqRW4B15pJjfGEbvbh2UzYndCVo+77 N1FspbANkjIFlgsbIths1yRTkZn96LSey4pyVEtcjyIyIl1pN7wGTJlzQVBfjjs5BVvl Lv8d9LdDd7Vn+H5Ep3pIo/tfLfgY9/iGZlKmk48EtsK4dez81+xQiDDfzeoBXnn2m4Ot lgxWEChUFE7/VLSKZ5hsZoRIr/3k1hE0aOcvpUXPsmdytgtu0VUVo4nYXGbOfdgNPlEd cwpQ== X-Forwarded-Encrypted: i=1; AJvYcCVDp/uI60Lle5wKDOJwvPg1//sY5SS2SoDzypbE7hmxHu/nJSvfmCCplUZBDcwlCNe9HatGQg1xb261tqpydE8= X-Gm-Message-State: AOJu0Yz70hqCAM8aNrHcZF/sdAN9/qwmzyUbenuAaBG0kA8x81BAX9gc s3N5q3zQTvbTNeTR7NQseETzEjnzcqtajyc21z80dFtaMNXQJi7vE8OYAL1/9h1avOwFxSWAD99 NXZPGRzPCfJh0ImOwfetsDUjIb4/ksutBm1qyPA== X-Google-Smtp-Source: AGHT+IEH9rI4S6KlwCKkzjkqT52M7y3/K2jSPa1QaJBGp/zOZOVcEiL/H79TZxHVkibmT7mzP8jGnaio+n2Sbwtx664= X-Received: by 2002:a17:906:c310:b0:a45:6423:ad94 with SMTP id s16-20020a170906c31000b00a456423ad94mr875878ejz.43.1709548970283; Mon, 04 Mar 2024 02:42:50 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: <87le6y7303.fsf@euler.schwinge.ddns.net> From: Christophe Lyon Date: Mon, 4 Mar 2024 11:42:47 +0100 Message-ID: Subject: Re: Help needed with maintainer-mode To: Thomas Schwinge Cc: Sam James , Mark Wielaard , binutils@sourceware.org, gcc@gcc.gnu.org, gdb-patches@sourceware.org, David Malcolm , arsen@gentoo.org, Alexandre Oliva Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,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: 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 patc= hes [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 usin= g > > autotools otherwise. > > > > I didn't yet play with maintainer-mode myself but I also didn't see muc= h > > point given I knew of more fundamental problems like this. > > > > [0] https://inbox.sourceware.org/gcc-patches/oril72c4yh.fsf@lxoliva.fsf= la.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=3D$(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 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=C3=BC=C3=9Fe > Thomas