From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) by sourceware.org (Postfix) with ESMTPS id D68F43858D28; Mon, 4 Mar 2024 11:25:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D68F43858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D68F43858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::12f ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709551544; cv=none; b=E3UMojew4yt4sCTGvMnQpRBgKXypi7oxdnQ1JILL93jpSi8nkGzkymX39ISS8ROgj29X2Ky8THza/0RF2kIjxA1MuN+6/Tl/YMNxb8OITZ8wd4baQ8jEkaHSLyUGsP+jTTJC7tEezkoTEidXDPy9Ex3avHURUtjt9s7Dki8v68c= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709551544; c=relaxed/simple; bh=6LIV7u3/ffuEup9kAROtdd3xUaJhyPNKBEmb2IMpv2M=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=xrjimpSJ/q/WVomRlTkdL7Ez4ksdG3QZYQEbfzIb4UQ6wKURlnPPFY4Zjqx/NWN2CPQgknfH4Om7WTweTeSlJ7iyAfCgiliLES82OcOnfaOqPSWnJgpnQQYyRxkslYvASao8xEcsoXitKfVH1vA3Fz3uO7VYt3108gV98NoGSww= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lf1-x12f.google.com with SMTP id 2adb3069b0e04-512e4f4e463so4416268e87.1; Mon, 04 Mar 2024 03:25:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709551540; x=1710156340; 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=A4m4xwv9ecbUkwbkv2iJ2SaL5chB4aqhQhaPsOw/wY0=; b=HUDrcV06HZqVrQZNyf604u/CFs0IXga/04P1OnI/53sn26/tzwqhIF8qy8BR334+J1 EhH22SQ4XgjwZm36Z3cAopvsp/k1j5Vv2Am5vTN7dviaSLQem6bCvRnd01J8mOSXORbW IevWr4WJrehImRpYrCL2E6kBIS/LrH2LM0niDFuMYUlnM0Oj2Ic5BzCH02eh7/WQOu7U PFOCsW17639vv3z5pZj9wjb5tXwu4xhDJAddme9JHpZfgkwLqcx2oQ767mdIHkKJY3/y wSWg48IxxSVoNQCcQkFkmcu+n5M47bNmSKP6ufwi5R00f4aCbfZNGSDRJaMJ2hUgoKV0 zKXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709551540; x=1710156340; 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=A4m4xwv9ecbUkwbkv2iJ2SaL5chB4aqhQhaPsOw/wY0=; b=of534QvGU+lSd5PyBvEVDXG/tKYtO6bzDH1HW3uaGDArjhh7BGyPMsAkvLO9HGYWGT bwW66PJIjSVikWFw2hGAt2OALEB7/RQ/pl7wSvXw4piuPC3z5qfuZWQenf8hTpCOZ7lq gn/RVyA6YiKdTx7nzTG/dOeKdgsCUNcotBITBI2BYTX4FOTtaQDbaIXU0egn0N4raZKD hh2fHDVWcE3d31N4Pabi5IGGILL4jIGpr/3D36DdqhT5D32Krp7mXBEpcE1uHJRb7nXR 6pfMykXrSbQpr/KMLwmiyxeTY1TJe25CdYBA6TG/9WFfJvL4a1n6HsfwB+mbCtPO0R5m S/Gg== X-Forwarded-Encrypted: i=1; AJvYcCURNsSDgrZJsNIn8lrtgJMuvJBfMy6d69yusjLzfb144P9OZ71zP+Q+kCreBJgycFehW6eRPjaLFzxQsUhXWwYoTPg4pExc0GK5cCPgZN4bLKStVA== X-Gm-Message-State: AOJu0Yx4mKW2oKxL0CrnGK66uwVpUiFGn9Ytr2lTZvsec8nOFHSGXzQQ F641aIby9hPc7TWQxSEKX8C8wDP5SC0+ryDiArKHHxzYxSYI5rFhbk5xhTId7j6NxWjco9qMuJN mUL5Vh6N2p5GBhRamN4mikZ05p3Q= X-Google-Smtp-Source: AGHT+IEs1c8LXpMp4TCK5QB6A34zyPz6NQbLnCjXOzibAYi72MnX57mK/AJz365HkvYXJxXAslMfoKdFhIbnUYl7Ro4= X-Received: by 2002:a05:6512:12ca:b0:512:f68b:69e7 with SMTP id p10-20020a05651212ca00b00512f68b69e7mr7387948lfg.16.1709551539802; Mon, 04 Mar 2024 03:25:39 -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: From: Jonathan Wakely Date: Mon, 4 Mar 2024 11:25:28 +0000 Message-ID: Subject: Re: Help needed with maintainer-mode To: Christophe Lyon 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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: On Mon, 4 Mar 2024 at 10:44, Christophe Lyon via Gcc wrot= e: > > Hi! > > On Mon, 4 Mar 2024 at 10:36, Thomas Schwinge wro= te: > > > > 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 base= d > > >>> 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 tha= t > > >> 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 pa= tches [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 us= ing > > > autotools otherwise. > > > > > > I didn't yet play with maintainer-mode myself but I also didn't see m= uch > > > point given I knew of more fundamental problems like this. > > > > > > [0] https://inbox.sourceware.org/gcc-patches/oril72c4yh.fsf@lxoliva.f= sfla.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 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 > > 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