From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id VKKBLmUjzGDBPwAAWB0awg (envelope-from ) for ; Fri, 18 Jun 2021 00:39:01 -0400 Received: by simark.ca (Postfix, from userid 112) id A3EF01F163; Fri, 18 Jun 2021 00:39:01 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 45CB71E01F for ; Fri, 18 Jun 2021 00:38:57 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7D27F388A435 for ; Fri, 18 Jun 2021 04:38:56 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7D27F388A435 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1623991136; bh=SDxra7QY3ijlBhhxD7TNAKEwteNPb8Xz89h2x462IrM=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=fWYvnS4Sw9L59YqQm/hOmA4WoUY9PxocSm3ZrgtCnan3sVTVdhhn+sU7pXCbr8Flu KH8b4Zv44rx64nTCd3fd5AD98CvEgeEA1KmELoMhSytMHj20q2KGG1m2mxR8xUSnIj fxvBMO7RD8Mm895JL9Zx/4kMd/CFGEH64zL7B2bc= Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by sourceware.org (Postfix) with ESMTP id 306E33857810 for ; Fri, 18 Jun 2021 04:38:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 306E33857810 Received: from vapier (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 4C2EC340B29; Fri, 18 Jun 2021 04:38:33 +0000 (UTC) Date: Fri, 18 Jun 2021 00:38:31 -0400 To: Simon Marchi Subject: Re: [PATCH] gdb/gdbserver: switch to AC_CONFIG_MACRO_DIRS Message-ID: Mail-Followup-To: Simon Marchi , gdb-patches@sourceware.org References: <20210615054416.1232-1-vapier@gentoo.org> <33565c24-0468-1ded-63db-d7ef402d5329@polymtl.ca> <5ece9821-45a3-14f6-33a1-3506b6efe72f@polymtl.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5ece9821-45a3-14f6-33a1-3506b6efe72f@polymtl.ca> X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Mike Frysinger via Gdb-patches Reply-To: Mike Frysinger Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 17 Jun 2021 10:43, Simon Marchi via Gdb-patches wrote: > On 2021-06-17 12:21 a.m., Mike Frysinger wrote: > > On 16 Jun 2021 22:30, Simon Marchi wrote: > >> On 2021-06-15 1:44 a.m., Mike Frysinger via Gdb-patches wrote: > >>> These dirs don't use automake, so use AC_CONFIG_MACRO_DIRS to specify > >>> ../config as a search dir for m4 macros. This allows removal of a lot > >>> of hand-written m4_include's from acinclude.m4 files, and simplifies > >>> use of `aclocal` or `autoreconf` as manual -I is not needed. > >> > >> For some reason, I get this when reconfiguring gdb: > >> > >> configure.ac:531: warning: macro 'AM_ICONV' not found in library > >> > >> The result looks ok, the resulting configure looks fine, but if you > >> happen to know why... > > > > i don't know why automake is able to find some of the ../config/ m4 files > > just fine, but a few others it barfs on. i don't see the warning because > > i have gettext installed and automake finds the system iconv.m4. > > There seems to be a special case for printing that warning for AM_* > macros: > > https://github.com/autotools-mirror/automake/blob/e7724fb1b7b97f662caf154414e6f71ffcbd966c/bin/aclocal.in#L528-L540 > > I debugged aclocal as much as I could, and it seems to find AM_ICONV > just fine, with --verbose I see: > > aclocal: found macro AM_ICONV in ../config/iconv.m4: 104 > > Also, note that with `aclocal -I ../config` I do not see the warning... > but aclocal does support AC_CONFIG_MACRO_DIRS, so this difference is > surprising. > > So I'd be tempted to call that an aclocal bug, although a benign one. oof, i agree, that smells like an aclocal bug. i'm not sure i'd call it benign when it's indistinguishable from actual missing macros. for example: $ echo AM_FOO >> configure.ac $ aclocal configure.ac:121: warning: macro 'AM_FOO' not found in library $ echo $? 0 i think autoconf might fail (i hope that's always the case), but it feels a bit wrong for it to be disconnected as such. and hopefully people always check the exit code of their tools ;). > I'd suggest still just doing the right thing and removing all the > ../config/* includes, and just ignore the warnings. I'll try to open an > automake bug or ask on the mailing list eventually. this seems to go against our -Werror approach to things. i also suspect it'll trip up devs who waste time trying to figure out why there's this warning (and surely it's their problem because no one else in the project would allow this to creep in), which means a snowball effect for people. so all things considered, i think the explicit include to silence the warning is the right trade-off. we can add some comments explaining why they're there so that at least doesn't keep tripping us up. how about at the top of acinclude.m4: dnl NB: When possible, try to avoid explicit includes of ../config/ files. dnl They're normally found by aclocal automatically and recorded in aclocal.m4. dnl However, some are kept here explicitly to silence harmless warnings from dnl aclocal when it finds AM_xxx macros via local search paths instead of dnl system search paths. -mike