From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) by sourceware.org (Postfix) with ESMTPS id AF1003858D37 for ; Mon, 4 Mar 2024 14:46:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AF1003858D37 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 AF1003858D37 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::533 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709563622; cv=none; b=VtaRSDRgPwaJK088/h5zOFvwqm+MTFwT4Q0gQGTxCdmdmky7XJoGafVLnpgfGlHvyjStpXynj5XwvLua3OZTULxeDjnBkcDmkeHDka1Nrcd6MHAGGqnqrPF21yH4iUkKjb9ZZCw9zyfW+TI1vlVv+jQWUD6b9rDlbusgxLT2elo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709563622; c=relaxed/simple; bh=pxDx22NwfiDNEb3CQj7Bcv7jjzPXljriLa5RLbUmQ1k=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=FRxRpgRkAwz27Q1pEMEYZNMmAFjk1heiDrHidzlop+C8g8SmZR/MtX51V1D8DMqqGi2Rdny1IkQRjWqtZctRS/FFa4TUvJ9yk8pxuWrstMpmvZhUcM3SmpedZGQzAyv/vKYmXvSFSAg82AgXyPyXTWS4znMlxvkiS7WNXVbQogA= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-56694fdec74so5134960a12.1 for ; Mon, 04 Mar 2024 06:46:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1709563618; x=1710168418; 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=RN5xGyeoReUSXElTipDKGhLSdP/1n2mIGXIkv39fJdg=; b=N6+sDGR1EBgp3pFySUMKAAJoDd18Mcn0ghNQ/Sx2pjVh4Dz3sQK2ENKObn6KciFTGj EqxZxUmxoaazgu/C4Yjq+1A4ij1fHj49OFWtt9Qu8D28yb6Gocc8k5W9iaSAOcXh3vI+ evxpZY9ivwCB1qSqJ8vTZSGdeW1GmP4LEpmHyMmy1lL68KG7slJUTFsvh+SHMIXfO3qU y/JE1GogKODvFCqdFuy+Y652fdKBRSEYCxOtV9hYvYiZWvoSmMo71nVoJjtWFzg8BFbX y2s7TtU5EDpQ3uxrB0FBc4Mf8yXnBvEta6bxAvGZn+yp/LDlF+kYkiif31mQ5Z+hOMbu B/rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709563618; x=1710168418; 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=RN5xGyeoReUSXElTipDKGhLSdP/1n2mIGXIkv39fJdg=; b=j6C1S7EWrUq8jaEKhEpNxFkZAS9YC1qhc71MhsrUKmaXRxcfaT9TrHWUi45695wY2T EdZus45aJBTkLi2FEurwPeUkPg6h5lBILm968p+ORpM6sHr1Gg0KZR9/rKVxyjvzxiW4 NgKup6uh4odJEtNtNgFhgkNGTi+mg6Nucc2uCMGgp6bQ3A83HDUMCR0PVZ73GqisIUg2 ztz0rjvyL6oyB/42EefNPpnHBjSugXDEAXgMzZ2ifiGc/Y7QGdRcT6Oa7oDyq7KWd3TZ T8784gv6g9zdA70mpKZyS6bFpoOH0N5TTronrdHIt8TPEk3PIJn+xBL+ApniDfaUaUAu acSg== X-Forwarded-Encrypted: i=1; AJvYcCXWkGmt7/AUqjn57xQpXL4TR1aTUOU7GbqqzMjraJtBusQLurSGb2sP6UJGeU/9GRa39FsK8gybslmQyNsw9RY= X-Gm-Message-State: AOJu0YyQGKB4AdgwZDdGuym856qcnqKFnvDfUhVJ9MFSTgxKWkvKH1uG TrsXmLc1GkdNGBGueabnufBKlhRZT0pL87xSRqSRKJVQ2LpVioHoN+aULE+fpwB7Af8wPLAIlFH Et5/p/9p8ArJsOGpd19eATpGqiswnSwZOhC3fCg== X-Google-Smtp-Source: AGHT+IFDnmoG1GsfxJwNBYt6bYCFZhrqW84eiT7A0hbVtxGU7c/38DNCOSZI0cGdM5NQl4FNUzQb6Ea0jhQz6KRs96A= X-Received: by 2002:aa7:d7cb:0:b0:567:6c79:c6ef with SMTP id e11-20020aa7d7cb000000b005676c79c6efmr898450eds.29.1709563618151; Mon, 04 Mar 2024 06:46:58 -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: Christophe Lyon Date: Mon, 4 Mar 2024 15:46:55 +0100 Message-ID: Subject: Re: Help needed with maintainer-mode To: 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.2 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: On Mon, 4 Mar 2024 at 12:25, Jonathan Wakely wrote: > > On Mon, 4 Mar 2024 at 10:44, Christophe Lyon via Gcc wr= ote: > > > > Hi! > > > > On Mon, 4 Mar 2024 at 10:36, Thomas Schwinge w= rote: > > > > > > 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 ba= sed > > > >>> on a script from Martin Liska, do you know/remember why it follow= s 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 bo= th > > > >> 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 t= hat > > > >> 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 simpl= e > > 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 > 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 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=C3=BC=C3=9Fe > > > Thomas