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 2063E3858CDA for ; Thu, 29 Feb 2024 10:41:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2063E3858CDA 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 2063E3858CDA 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=1709203270; cv=none; b=lPu6uXFdmWWEIN1S343HOH/1smCf02qHt86KYobXxOY2rNsPBdquTIN4tx0w9PvA6br8mke2L3H2hbvI7VG4wkHvbNDZA5CuBjUp+kTIFxss+azzlBU6ElSBhV8FOx8Rgc+XPVBqf97FEfhTQ11LFKHKY/QvRCchoNSvIXti7YU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709203270; c=relaxed/simple; bh=d1acZSZgog9wl/SvtSIrpFbXkbYkhl5TuIN/C+StsP0=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=YgEKYMeJkgazo7B126PfHuJZw0022GUcgAC34EcCc6DEAaQA2dCpMf9Ok3l8909e7eggAfY856WL8K7eTfiLm7MjmQjOXdtZD8KSCnbRVdKYjYxl+b09Aa5sSyyvoSSdZ9y7dNXS3upIlPW37UFXGTNKvr1HYMxknIEYzEDcEuI= 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 A25C81FB; Thu, 29 Feb 2024 02:41:46 -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 0DD393F762; Thu, 29 Feb 2024 02:41:06 -0800 (PST) Message-ID: <66f6bb34-e7c3-4bc4-8c37-845aee81f6fe@arm.com> Date: Thu, 29 Feb 2024 10:41:05 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Help needed with maintainer-mode Content-Language: en-GB To: Christophe Lyon , binutils@sourceware.org, GCC Mailing List , gdb-patches@sourceware.org References: From: "Richard Earnshaw (lists)" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3491.6 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,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 29/02/2024 10:22, Christophe Lyon via Gcc wrote: > Hi! > > Sorry for cross-posting, but I'm not sure the rules/guidelines are the > same in gcc vs binutils/gdb. > > TL;DR: are there some guidelines about how to use/enable maintainer-mode? > > In the context of the Linaro CI, I've been looking at enabling > maintainer-mode at configure time in our configurations where we test > patches before they are committed (aka "precommit CI", which relies on > patchwork). > > Indeed, auto-generated files are not part of patch submissions, and > when a patch implies regenerating some files before building, we > currently report wrong failures because we don't perform such updates. > > I hoped improving this would be as simple as adding > --enable-maintainer-mode when configuring, after making sure > autoconf-2.69 and automake-1.15.1 were in the PATH (using our host's > libtool and gettext seems OK). > > However, doing so triggered several problems, which look like race > conditions in the build system (we build at -j160): > - random build errors in binutils / gdb with messages like "No rule to > make target 'po/BLD-POTFILES.in". I managed to reproduce something > similar manually once, I noticed an empty Makefile; the build logs are > of course difficult to read, so I couldn't figure out yet what could > cause this. > > - random build failures in gcc in fixincludes. I think this is a race > condition because fixincludes is updated concurrently both from > /fixincludes and $buillddir/fixincludes. Probably fixable in gcc > Makefiles. > > - I've seen other errors when building gcc like > configure.ac:25: error: possibly undefined macro: AM_ENABLE_MULTILIB > from libquadmath. I haven't investigated this yet. > > I've read binutils' README-maintainer-mode, which contains a warning > about distclean, but we don't use this: we start our builds from a > scratch directory. > > So... I'm wondering if there are some "official" guidelines about how > to regenerate files, and/or use maintainer-mode? Maybe I missed a > "magic" make target (eg 'make autoreconf-all') that should be executed > after configure and before 'make all'? > > I've noticed that sourceware's buildbot has a small script > "autoregen.py" which does not use the project's build system, but > rather calls aclocal/autoheader/automake/autoconf in an ad-hoc way. > Should we replicate that? > > Thanks, > > Christophe There are other potential gotchas as well, such as the manual copying of the generated tm.texi back into the source repo due to relicensing. Perhaps we haven't encountered that one because patches generally contain that duplicated output. If we want a CI to work reliably, then perhaps we should reconsider our policy of stripping out regenerated code. We have a number of developer practices, such as replying to an existing patch with an updated version that the CI can't handle easily (especially if the patch is part of a series), so there may be space for a discussion on how to work smarter. My calendar says we have a toolchain office hours meeting today, perhaps this would be worth bringing up. R.