From unknown Thu Sep 11 09:17:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#12845: aclocal: stop handling AC_CONFIG_MACRO_DIR; handle just AC_CONFIG_MACRO_DIRS (was: Re: [PATCH 1/2] AC_CONFIG_MACRO_DIRS: new macro, mostly for aclocal Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Fri, 09 Nov 2012 18:03:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 12845 X-GNU-PR-Package: automake X-GNU-PR-Keywords: patch To: Nick Bowler Cc: 12845@debbugs.gnu.org, autoconf-patches@gnu.org, eblake@redhat.com, bunk@stusta.de X-Debbugs-Original-Cc: bug-automake@gnu.org, autoconf-patches@gnu.org, Eric Blake , Adrian Bunk Received: via spool by submit@debbugs.gnu.org id=B.1352484136560 (code B ref -1); Fri, 09 Nov 2012 18:03:01 +0000 Received: (at submit) by debbugs.gnu.org; 9 Nov 2012 18:02:16 +0000 Received: from localhost ([127.0.0.1]:58280 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TWsuF-00008y-U5 for submit@debbugs.gnu.org; Fri, 09 Nov 2012 13:02:16 -0500 Received: from eggs.gnu.org ([208.118.235.92]:38699) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TWsuD-00008o-2u for submit@debbugs.gnu.org; Fri, 09 Nov 2012 13:02:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TWsu0-00067V-9f for submit@debbugs.gnu.org; Fri, 09 Nov 2012 13:02:04 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:59609) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TWsu0-00067Q-73 for submit@debbugs.gnu.org; Fri, 09 Nov 2012 13:02:00 -0500 Received: from eggs.gnu.org ([208.118.235.92]:42872) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TWstw-0004a4-7c for bug-automake@gnu.org; Fri, 09 Nov 2012 13:02:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TWstr-000648-Cl for bug-automake@gnu.org; Fri, 09 Nov 2012 13:01:56 -0500 Received: from mail-bk0-f41.google.com ([209.85.214.41]:51049) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TWstn-00063N-V9; Fri, 09 Nov 2012 13:01:48 -0500 Received: by mail-bk0-f41.google.com with SMTP id jm1so1921877bkc.0 for ; Fri, 09 Nov 2012 10:01:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Zkkph1bDARWdwZKkV9rPOzfHm9UfXiCm5bz5yUb2I60=; b=MrjJntp0bK1zSnL638du5q1fZCPnc8YRqxwDeORp8o5858tGvrDGcSG1V5kzBgbE6C DhhJ8lGa+dTrNDhrEdqYi28P8FOWqsMKoQG0t0SiUAe3/gJYeYji5a4pIWgC9dapk/Cy NXPIDcCW/XHJKw4EfNoyboXnYGsCpy4Yy0PTmPX8JLC68NWIcCfQGkWmqVzK3A5AZfuY Q7lqGNbb7nT2y38clNiMITxltxxqPe7PGZXiJHpBpV9D3jqCBUReAQSORiPIR4xE+R4l k2m7vX4+iMrn9sV5M+tqZU82c+uhONPWNhyyLJoaKoT96Zn/A4segFlbCtQ1JYnFp2TO 6VvA== Received: by 10.204.146.83 with SMTP id g19mr4121374bkv.33.1352484106695; Fri, 09 Nov 2012 10:01:46 -0800 (PST) Received: from [192.168.178.21] (host247-100-dynamic.8-87-r.retail.telecomitalia.it. [87.8.100.247]) by mx.google.com with ESMTPS id z22sm19740976bkw.2.2012.11.09.10.01.43 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 10:01:45 -0800 (PST) Message-ID: <509D44FF.5010002@gmail.com> Date: Fri, 09 Nov 2012 19:01:35 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <507E5D75.5040306@gmail.com> <529492dab6dec00f88c5e54adf8f257c5470fd74.1350468731.git.stefano.lattarini@gmail.com> <5094311D.2040801@redhat.com> <509465EB.1000701@gmail.com> <20121109160001.GF8324@bunk.dyndns.info> <20121109163334.GA3105@elliptictech.com> In-Reply-To: <20121109163334.GA3105@elliptictech.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -3.4 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.4 (---) [+cc bug-automake] On 11/09/2012 05:33 PM, Nick Bowler wrote: > On 2012-11-09 18:00 +0200, Adrian Bunk wrote: >> On Sat, Nov 03, 2012 at 01:31:39AM +0100, Stefano Lattarini wrote: >>> On 11/02/2012 09:46 PM, Eric Blake wrote: >>>> On 10/17/2012 04:15 AM, Stefano Lattarini wrote: > [...] >>>> Hmm, I'm wondering if we should do something fancier, and have both >>>> AC_CONFIG_MACRO_DIR and AC_CONFIG_MACRO_DIRS collaborate so that the >>>> FIRST call to either macro causes AC_CONFIG_MACRO_DIR to be traced. >>>> >>> Considering that I'd like to see AC_CONFIG_MACRO_DIR deprecated in >>> Autoconf 2.71 and removed in Autoconf 2.72, I believe that would be >>> a bit of an overkill. >>> ... >> >> It is completely crazy to imagine removing a macro in Autoconf 2.72 >> that is as of today used in half of all configure.ac files. [1] >> >> Did you ever consider the consequences e.g. for Debian, where more than >> thousand packages are re-running autoconf at package build time? >> "We have to fix 1000 packages before we can upgrade to autoconf 2.72 >> in Debian" sounds like a pretty horrible situation for both Debian >> and autoconf. >> >> Marking it as deprecated in Autoconf 2.71 with a possible removal >> 10 years later sounds like a more realistic schedule. > > To be honest I don't see the point in removing the macro ever, since > it doesn't actually do anything. > Good point. Unfortunately, the current development version of aclocal has started to recognize and handle AC_CONFIG_MACRO_DIR. But we can easily change that once 'AC_CONFIG_MACRO_DIRS' is implemented, by having aclocal recognize only this later macro; and we can do so without any backward-incompatibility, since the code handling AC_CONFIG_MACRO_DIR has not made it into any released aclocal version. I'm CC:ing this message to the bug-automake list so that I won't forgot about the issue ... > Removing it from the documentation > (except perhaps for historical reference) and marking it deprecated > would be prudent, however. > > By the same token, to avoid any regressions, let's not change the > behaviour of AC_CONFIG_MACRO_DIR by suddenly making it do more than > nothing. > I agree; and as I said, I plan to remove aclocal's new-found ability to handle AC_CONFIG_MACRO_DIR before releasing Automake 1.13. Thanks, Stefano From unknown Thu Sep 11 09:17:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#12845: aclocal: stop handling AC_CONFIG_MACRO_DIR; handle just AC_CONFIG_MACRO_DIRS Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Sat, 10 Nov 2012 12:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12845 X-GNU-PR-Package: automake X-GNU-PR-Keywords: patch To: Nick Bowler Cc: autoconf-patches@gnu.org, eblake@redhat.com, 12845@debbugs.gnu.org, bunk@stusta.de Received: via spool by 12845-submit@debbugs.gnu.org id=B12845.135255074114516 (code B ref 12845); Sat, 10 Nov 2012 12:33:02 +0000 Received: (at 12845) by debbugs.gnu.org; 10 Nov 2012 12:32:21 +0000 Received: from localhost ([127.0.0.1]:58983 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TXAEX-0003m4-6d for submit@debbugs.gnu.org; Sat, 10 Nov 2012 07:32:21 -0500 Received: from mail-ee0-f44.google.com ([74.125.83.44]:52247) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TXAEV-0003lu-Hb; Sat, 10 Nov 2012 07:32:20 -0500 Received: by mail-ee0-f44.google.com with SMTP id d4so2891080eek.3 for ; Sat, 10 Nov 2012 04:32:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=JCjZRBgPlZ86ROtF9Z4o07sgs7L3/ER8xh4RVv4NcxE=; b=KX0yYI9EAiXn2M6QoUR8OSpmQkpFOgtERj/jZZwO5FfPi5iTe9pnpdPpoSGIUgWBug uuZLkwYJbE1b7UkFUx5t05EMG52Cx4NjiHSrlP9oQT0kEPRp6eM+qXcxw5FYfXS1Vrsi gZa9QOWNYlVATjv1VxOK5YlDclO3QPffYqiLgr6xR2bF2d4fdqaXGs7GznByZt35iUbN YNc6XUvsP7H6RmggswhW1TnmjpPDdufaydZfdaM67cclm5Yom29BOVTyxJpr96YjLJGx gDcigNXRxKIpT2/2tu8aApF/cazcIoq+RFrWXYFTq+e/Pii4+ZCM2q8z3VNroRNhjI5d 3FQA== Received: by 10.14.215.69 with SMTP id d45mr45714130eep.16.1352550725741; Sat, 10 Nov 2012 04:32:05 -0800 (PST) Received: from [192.168.178.21] (host247-100-dynamic.8-87-r.retail.telecomitalia.it. [87.8.100.247]) by mx.google.com with ESMTPS id g5sm3263013eem.4.2012.11.10.04.32.03 (version=SSLv3 cipher=OTHER); Sat, 10 Nov 2012 04:32:04 -0800 (PST) Message-ID: <509E4941.2050807@gmail.com> Date: Sat, 10 Nov 2012 13:32:01 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <507E5D75.5040306@gmail.com> <529492dab6dec00f88c5e54adf8f257c5470fd74.1350468731.git.stefano.lattarini@gmail.com> <5094311D.2040801@redhat.com> <509465EB.1000701@gmail.com> <20121109160001.GF8324@bunk.dyndns.info> <20121109163334.GA3105@elliptictech.com> <509D44FF.5010002@gmail.com> In-Reply-To: <509D44FF.5010002@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) tags 12845 wontfix close 12845 thanks On 11/09/2012 07:01 PM, Stefano Lattarini wrote: > > I agree; and as I said, I plan to remove aclocal's new-found ability > to handle AC_CONFIG_MACRO_DIR before releasing Automake 1.13. > On a second thought, that would cause extra confusion in the client packages, and several problems in the Automake test suite. So I'll keep the support for AC_CONFIG_MACRO_DIR, while advising the use of AC_CONFIG_MACRO_DIRS in the documentation. This seems the simplest solution (and gosh, we've had already had way too much complications in the implementation of this apparently simple feature!). Regards, and sorry for the noise, Stefano From unknown Thu Sep 11 09:17:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#12845: [PATCH] AC_CONFIG_MACRO_DIRS: improve tracing and add sanity checks Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Tue, 13 Nov 2012 20:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12845 X-GNU-PR-Package: automake X-GNU-PR-Keywords: patch wontfix To: Nick Bowler Cc: autoconf-patches@gnu.org, Eric Blake , 12845@debbugs.gnu.org, Adrian Bunk Received: via spool by 12845-submit@debbugs.gnu.org id=B12845.1352837855777 (code B ref 12845); Tue, 13 Nov 2012 20:18:02 +0000 Received: (at 12845) by debbugs.gnu.org; 13 Nov 2012 20:17:35 +0000 Received: from localhost ([127.0.0.1]:39335 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYMvM-0000CP-70 for submit@debbugs.gnu.org; Tue, 13 Nov 2012 15:17:35 -0500 Received: from mail-bk0-f44.google.com ([209.85.214.44]:53383) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYMvJ-0000CD-Am; Tue, 13 Nov 2012 15:17:30 -0500 Received: by mail-bk0-f44.google.com with SMTP id w11so408854bku.3 for ; Tue, 13 Nov 2012 12:16:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=YFdA1XJ9/AVlwmJWTUzFFgRzJgqsO/LLHwuqMUlSotU=; b=vxRzg8Ugl7pCE94ZBG6UY7Xh+vNY7ueAYMO74qM7ElfE75sEiV25rA64EihiysmBKI Mz8zp79kPjlkYQnjeBMPKphLlfvWURjOm4Ly+gQ+ZazQzlnWBch3Rx+Bh48J7mNAFRyk fZxdHlaHbVKjk+DVA91SrhsxrOM2hhodImc0HhqG12HoqPeBzhhI2D3J+GOI/phAIzSt TF6xDh4eu1rvJ04CRX8eyDashyMz5fZ2/mJH/5Fco5ns9ceetmlS2cJ3Ltwjzkmi6n3d YWwLm3hIiRAwh+W4eYCWmvnnhZgtloPf27GPJ/y/6u85dBgGHj5Q4inDXIihrcdZAjm+ ZNkA== Received: by 10.204.154.82 with SMTP id n18mr6658314bkw.56.1352837817014; Tue, 13 Nov 2012 12:16:57 -0800 (PST) Received: from [192.168.178.21] (host247-100-dynamic.8-87-r.retail.telecomitalia.it. [87.8.100.247]) by mx.google.com with ESMTPS id gy18sm6696438bkc.4.2012.11.13.12.16.54 (version=SSLv3 cipher=OTHER); Tue, 13 Nov 2012 12:16:56 -0800 (PST) Message-ID: <50A2AAB2.4090200@gmail.com> Date: Tue, 13 Nov 2012 21:16:50 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <20121112191025.GA22213@elliptictech.com> <50A1510C.8000001@redhat.com> <20121112204050.GA22609@elliptictech.com> <20121112220112.GA1712@bunk.dyndns.info> <20121112221323.GA23877@elliptictech.com> <50A175F9.9090200@redhat.com> <20121112224129.GA24020@elliptictech.com> <20121112231213.GB1712@bunk.dyndns.info> <20121113143045.GA27271@elliptictech.com> <20121113185145.GA29576@bunk.dyndns.info> <20121113194408.GA26711@elliptictech.com> In-Reply-To: <20121113194408.GA26711@elliptictech.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) reopen 12845 thanks [+cc automake bug 12845; reopening it] On 11/13/2012 08:44 PM, Nick Bowler wrote: > On 2012-11-13 20:51 +0200, Adrian Bunk wrote: >> On Tue, Nov 13, 2012 at 09:30:45AM -0500, Nick Bowler wrote: >>> On 2012-11-13 01:12 +0200, Adrian Bunk wrote: >>>> In the future libtool will use the result of tracing >>>> AC_CONFIG_MACRO_DIR_TRACE instead of grep'ing configure.ac. >>> >>> So what you are saying is that this change is a "workaround" for a >>> planned regression in libtool. Why are we planning to regress libtool? >>> Why can't libtool just continue to do what it's always done for packages >>> that don't make use the new feature (AC_CONFIG_MACRO_DIRS)? >> >> The cleanest solution is to handle AC_CONFIG_MACRO_DIR in autoconf, >> without making libtool and other users like automake bother about >> whether AC_CONFIG_MACRO_DIR or AC_CONFIG_MACRO_DIRS is present. >> >> Handling that in one place is much better than having the same logic >> duplicated in multiple places. > > Unfortunately, this "cleanest" solution of moving everything into > Autoconf will, by definition, break any package that relies on the > existing, longstanding behaviour that AC_CONFIG_MACRO_DIR doesn't > actually do *anything* (OK, it can cause libtool to print fewer > messages). > > Right now, you can put *absolutely anything* you want as the argument(s) > to this macro, and it will work perfectly fine if you're not using > libtool. Let's put it another way: in the non-libtool case, nobody has > ever tested their use (if any) of AC_CONFIG_MACRO_DIR, because it has > never done *anything at all* in this case (equivalent to dead code). > Since untested code is broken code, suddenly making this code live again > is almost certain to break real packages. > > Even if you are using libtool, all libtool does is check (extremely > poorly) that the first -I option in ACLOCAL_AMFLAGS matches the argument > of the last AC_CONFIG_MACRO_DIR invocation. This is a little better > than the non-libtool case, but the check itself has so many bugs that it > basically amounts to zero testing again except in the most trivial case. > > I believe I have already shown several examples of how packages might be > relying on the existing behaviour and would be broken by these changes > to Autoconf together with support for AC_CONFIG_MACRO_DIR_TRACE in > future tools. > >>> If libtool plans on removing compatibility with packages that have >>> worked fine for 10 years or longer, then that is a separate problem, >>> and one that I would argue against just as strongly. >> >> libtool does not plan that. > > Well that's good to hear. You had me going for a moment. > >>> But I have a better idea: let's not remove features (it's OK to stop >>> documenting them) if we don't absolutely have to, then there will be >>> no regressions that we need to work around in Autoconf. >> >> There is no regression planned. > > Again, good to hear. > >> libtool will access the same information through a new way that has been >> implemented by this patch. > > But the old way will have to stick around for compatibility with older > packages that have not been updated to the New Way. So since we have to > keep the old way around anyway, why not just continue to use the old way > for old packages? This has the advantage of both not breaking any > existing packages, and not breaking any of the examples I've provided so > far. > > Packages that update to the New Way will gain access to the new > features, while packages that have not yet updated will continue to work > exactly as they did before... AND even my most contrived examples of how > things can be broken by this change will continue to work as they always > have. Is that not the best option? > > Cheers, > I must say I find Nick's arguments quite compelling by now. Eric, could we just deprecate AC_CONFIG_MACRO_DIR (in the documentation only for the moment, at least for a couple of releases), and point the users to AC_CONFIG_MACRO_DIRS exclusively? Or is there some reason not to do so that both I and Nick are missing? If Eric is OK with such a change, once it's done I'll also revert the aclocal's support for AC_CONFIG_MACRO_DIR (present only in the master branch so far, and not in any released automake versions, so no worries about backward compatibility there). BTW: Nick, if it suits you, would you care to post a shorter, self-contained rationale summarizing your points so far? So you'll finally convince us completely -- and we'll shamefully steal that rationale for our commit messages ;-) Best regards, Stefano From unknown Thu Sep 11 09:17:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#12845: [PATCH] AC_CONFIG_MACRO_DIRS: improve tracing and add sanity checks Resent-From: Eric Blake Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Tue, 13 Nov 2012 20:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12845 X-GNU-PR-Package: automake X-GNU-PR-Keywords: patch wontfix To: Stefano Lattarini Cc: Nick Bowler , 12845@debbugs.gnu.org, autoconf-patches@gnu.org, Adrian Bunk Received: via spool by 12845-submit@debbugs.gnu.org id=B12845.13528391936023 (code B ref 12845); Tue, 13 Nov 2012 20:40:02 +0000 Received: (at 12845) by debbugs.gnu.org; 13 Nov 2012 20:39:53 +0000 Received: from localhost ([127.0.0.1]:39364 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYNGy-0001Z6-Nl for submit@debbugs.gnu.org; Tue, 13 Nov 2012 15:39:53 -0500 Received: from mx1.redhat.com ([209.132.183.28]:27505) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYNGu-0001Yv-KU for 12845@debbugs.gnu.org; Tue, 13 Nov 2012 15:39:51 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qADKdFwJ015016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Nov 2012 15:39:16 -0500 Received: from [10.3.113.67] (ovpn-113-67.phx2.redhat.com [10.3.113.67]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qADKdDdM025372; Tue, 13 Nov 2012 15:39:14 -0500 Message-ID: <50A2AFF1.7010909@redhat.com> Date: Tue, 13 Nov 2012 13:39:13 -0700 From: Eric Blake Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 References: <20121112191025.GA22213@elliptictech.com> <50A1510C.8000001@redhat.com> <20121112204050.GA22609@elliptictech.com> <20121112220112.GA1712@bunk.dyndns.info> <20121112221323.GA23877@elliptictech.com> <50A175F9.9090200@redhat.com> <20121112224129.GA24020@elliptictech.com> <20121112231213.GB1712@bunk.dyndns.info> <20121113143045.GA27271@elliptictech.com> <20121113185145.GA29576@bunk.dyndns.info> <20121113194408.GA26711@elliptictech.com> <50A2AAB2.4090200@gmail.com> In-Reply-To: <50A2AAB2.4090200@gmail.com> X-Enigmail-Version: 1.4.5 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig33E783F74AB6948A33932B1F" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Spam-Score: -4.4 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -7.1 (-------) This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig33E783F74AB6948A33932B1F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/13/2012 01:16 PM, Stefano Lattarini wrote: >> But the old way will have to stick around for compatibility with older= >> packages that have not been updated to the New Way. So since we have = to >> keep the old way around anyway, why not just continue to use the old w= ay >> for old packages? This has the advantage of both not breaking any >> existing packages, and not breaking any of the examples I've provided = so >> far. >> >> Packages that update to the New Way will gain access to the new >> features, while packages that have not yet updated will continue to wo= rk >> exactly as they did before... AND even my most contrived examples of h= ow >> things can be broken by this change will continue to work as they alwa= ys >> have. Is that not the best option? The best option is that a package that uses the old way will work with new tools. And this is what we've done. That means: I write a configure.ac with a single AC_CONFIG_MACRO_DIR([dir]) AND a redundant ACLOCAL_AMFLAGS=3D-I dir. Old libtool uses 'dir' to decide whether to print a warning, and old autoreconf and aclocal just use ACLOCAL_AMFLAGS. Then, with that same configure.ac, I have several upgrade paths: 1. New autoconf, old automake and old libtool Autoreconf now sniffs AC_CONFIG_MACRO_DIR_TRACE instead of ACLOCAL_AMFLAGS for deciding what to pass to aclocal. No big deal - the two are already equivalent. Libtool and aclocal continue to work as they always have. 2. New automake, old autoconf and old libtool Automake now pays attention to AC_CONFIG_MACRO_DIR_TRACE, and can now do a sanity check that the first traced directory (dir) matches what is in ACLOCAL_AMFLAGS when that is present. Automake may choose to warn that ACLOCAL_AMFLAGS is deprecated, but things will still work. Libtool and autoconf continue to work as they always have. With this option, if you WANT to document secondary directories, but still allow another developer to bootstrap your package without upgrading automake, then you can add: m4_define_default([AC_CONFIG_MACRO_DIRS]) AC_CONFIG_MACRO_DIRS([secondary]) But such documentation should be redundant with the ACLOCAL_AMFLAGS that remains for use of old libtool and autoreconf. 3. New libtool, old autoconf and old automake Libtool now pays attention to AC_CONFIG_MACRO_DIR_TRACE, and continues to do a sanity check that it matches ACLOCAL_AMFLAGS when that is present. Autoconf and automake continue to work as they always have. 4. Upgrade everything, but don't rewrite configure.ac Things continue to work as they have 5. Upgrade everything, and decide that I no longer need to cater to older tools Edit configure.ac to AC_PREREQ([2.70]) and request automake 1.13 and the next libtool version Also edit configure.ac to use AC_CONFIG_MACRO_DIRS instead of AC_CONFIG_MACRO_DIR; at this point, you can finally list secondary directories Also edit Makefile.am to ditch ACLOCAL_AMFLAGS >> >> Cheers, >> > I must say I find Nick's arguments quite compelling by now. >=20 > Eric, could we just deprecate AC_CONFIG_MACRO_DIR (in the documentation= > only for the moment, at least for a couple of releases), and point the > users to AC_CONFIG_MACRO_DIRS exclusively? Or is there some reason not= > to do so that both I and Nick are missing? We _DID_ that. We documented that AC_CONFIG_MACRO_DIR is only around for back-compat reasons, and that if you use it, it must come first, and that AC_CONFIG_MACRO_DIRS provides everything else; but that if you are willing to assume new tools across the board, then you can ditch AC_CONFIG_MACRO_DIR, ditch ACLOCAL_AMFLAGS, and exclusively use AC_CONFIG_MACRO_DIRS. >=20 > If Eric is OK with such a change, once it's done I'll also revert the > aclocal's support for AC_CONFIG_MACRO_DIR (present only in the master > branch so far, and not in any released automake versions, so no worries= > about backward compatibility there). So far, you haven't convinced me that anything needs changing, beyond what we've already done. As far as I can tell, you are arguing that packages that use multiple AC_CONFIG_MACRO_DIR should continue to silently work, with confusing documentation rules, rather than autoconf flag that as suspicious usage; but that is independent of whether a single use of AC_CONFIG_MACRO_DIR will work. And if that is what you are proposing, then patches welcome. >=20 > BTW: Nick, if it suits you, would you care to post a shorter, > self-contained rationale summarizing your points so far? So > you'll finally convince us completely -- and we'll shamefully > steal that rationale for our commit messages ;-) Indeed - I still haven't been convinced that we've broken anything that wasn't already broken (namely, the rare package that uses AC_CONFIG_MACRO_DIR more than once). But if causing a hard error if AC_CONFIG_MACRO_DIR multiple times is what is bothering you, then perhaps it is a one-liner patch to turn it into a warning instead of an error. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig33E783F74AB6948A33932B1F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBCAAGBQJQoq/xAAoJEKeha0olJ0NqaxQIAIwNANlVUpsbBZVd1yWO0x04 P7QjnfYsVhC/zinvwR6eryI3wKm3aP8yn1BKXYqKYGRHYxyHz6VzcgeChvnVlxMb k28rjs8qHIhIP+VwSdcI2ZXVEq+RhrCdUN4sYCiYVl+B0w7srTEcyIBfoRul1dDI BTw9AxGYyJ8sEIMl+x5CBr4/VKdOmlILmP7Vi4tVwXqI5+hHpmQ8i2DxRbgEMW0w baM4LNqdmXrgk+7KRrOMmTjNPaUVkC/edCuKQBv9UI2O3SF3sKhAYdQExd4p4LjA WeA+2zP5xNmevTwqC/OEijqYl6n+pqHEUTJz0VQkQ5FcPGYZJ9JlzFRVENL5J5Q= =jtmA -----END PGP SIGNATURE----- --------------enig33E783F74AB6948A33932B1F-- From unknown Thu Sep 11 09:17:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#12845: [PATCH] AC_CONFIG_MACRO_DIRS: improve tracing and add sanity checks Resent-From: Nick Bowler Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Tue, 13 Nov 2012 21:37:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12845 X-GNU-PR-Package: automake X-GNU-PR-Keywords: patch wontfix To: Eric Blake Cc: autoconf-patches@gnu.org, Stefano Lattarini , 12845@debbugs.gnu.org, Adrian Bunk Received: via spool by 12845-submit@debbugs.gnu.org id=B12845.135284261411178 (code B ref 12845); Tue, 13 Nov 2012 21:37:01 +0000 Received: (at 12845) by debbugs.gnu.org; 13 Nov 2012 21:36:54 +0000 Received: from localhost ([127.0.0.1]:39480 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYOA9-0002uE-GD for submit@debbugs.gnu.org; Tue, 13 Nov 2012 16:36:54 -0500 Received: from mx.scalarmail.ca ([98.158.95.75]:62186 helo=ironport-01.sms.scalar.ca) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYOA7-0002u7-5b for 12845@debbugs.gnu.org; Tue, 13 Nov 2012 16:36:52 -0500 Received: from unknown (HELO sms-zimbra-mta-02.sms.scalar.ca) ([192.168.32.56]) by ironport-01.sms.scalar.ca with ESMTP; 13 Nov 2012 16:35:40 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by sms-zimbra-mta-02.sms.scalar.ca (Postfix) with ESMTP id 0B87F87C08; Tue, 13 Nov 2012 16:35:40 -0500 (EST) Received: from sms-zimbra-mta-02.sms.scalar.ca ([127.0.0.1]) by localhost (sms-zimbra-mta-02.sms.scalar.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKO5p5GYsYNe; Tue, 13 Nov 2012 16:35:39 -0500 (EST) Received: from mail.ellipticsemi.com (mail.elliptictech.com [209.217.122.41]) (Authenticated sender: nbowler@elliptictech.com) by sms-zimbra-mta-02.sms.scalar.ca (Postfix) with ESMTPSA id D9C0D87BD8; Tue, 13 Nov 2012 16:35:38 -0500 (EST) Date: Tue, 13 Nov 2012 16:35:38 -0500 From: Nick Bowler Message-ID: <20121113213538.GA13472@elliptictech.com> References: <20121112220112.GA1712@bunk.dyndns.info> <20121112221323.GA23877@elliptictech.com> <50A175F9.9090200@redhat.com> <20121112224129.GA24020@elliptictech.com> <20121112231213.GB1712@bunk.dyndns.info> <20121113143045.GA27271@elliptictech.com> <20121113185145.GA29576@bunk.dyndns.info> <20121113194408.GA26711@elliptictech.com> <50A2AAB2.4090200@gmail.com> <50A2AFF1.7010909@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50A2AFF1.7010909@redhat.com> Organization: Elliptic Technologies Inc. User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: 0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) On 2012-11-13 13:39 -0700, Eric Blake wrote: > On 11/13/2012 01:16 PM, Stefano Lattarini wrote: > >> But the old way will have to stick around for compatibility with older > >> packages that have not been updated to the New Way. So since we have to > >> keep the old way around anyway, why not just continue to use the old way > >> for old packages? This has the advantage of both not breaking any > >> existing packages, and not breaking any of the examples I've provided so > >> far. > >> > >> Packages that update to the New Way will gain access to the new > >> features, while packages that have not yet updated will continue to work > >> exactly as they did before... AND even my most contrived examples of how > >> things can be broken by this change will continue to work as they always > >> have. Is that not the best option? > > The best option is that a package that uses the old way will work with > new tools. And this is what we've done. That means: > > I write a configure.ac with a single AC_CONFIG_MACRO_DIR([dir]) AND a > redundant ACLOCAL_AMFLAGS=-I dir. Old libtool uses 'dir' to decide > whether to print a warning, and old autoreconf and aclocal just use > ACLOCAL_AMFLAGS. As I have already said, this is not the only "Old Way". I have never argued that this case was problematic, so I don't know why you are bringing it up in your example. Nevertheless, here are five specific possibilities, all of which I have mentioned already. All of these possibilities work with the latest versions of autoconf, automake and libtool, and I would expect (but have not tested) them to work with pretty much any combination since autoconf-2.57g. (0) Packages have a simple AC_CONFIG_MACRO_DIR([foo]) and a simple ACLOCAL_AMFLAGS = -I foo and don't do anything weird. I think all of us agree that this is the most common case. (1) Packages that use ACLOCAL_AMFLAGS to specify one or more macro directories and do *NOT* use AC_CONFIG_MACRO_DIR at all. You agreed earlier that this was a good choice for packages using more than one macro directory. I suspect it's also quite common in packages that aren't using libtool. For example, GNU Gettext appears to be in this category. (2) Packages that use a single AC_CONFIG_MACRO_DIR to only to shut up libtool, and specify more than one macro directory in ACLOCAL_AMFLAGS. You also agreed that this was a reasonable choice for package maintainers who need more than one macro directory. (3) Packages that use more than one AC_CONFIG_MACRO_DIR. You argue that this was broken to begin with. (4) Packages that aren't using libtool, tried to do (0), but for whatever reason AC_CONFIG_MACRO_DIR and ACLOCAL_AMFLAGS are out of sync. You argue that this was broken to begin with. For simplicity, let's only consider the following scenario: someone wants to autoreconf an old package using new (as-yet-unreleased) versions of Autoconf, Automake *AND* Libtool. * With this patch to Autoconf, I'm not sure how anyone can possibly add support for AC_CONFIG_MACRO_DIR_TRACE to either aclocal or libtoolize without causing Old Way (2) to fail, without an absurd amount of extra complexity and weird behaviour. * Maintaining support for both Old Ways (1) and (2) implies that we cannot remove the ACLOCAL_AMFLAGS snarfing code from either libtoolize or autoreconf. * Since we must keep the ACLOCAL_AMFLAGS snarfing code, it seems that the easiest way to maintain support for Old Ways (0), (1) *AND* (2) is to use the ACLOCAL_AMFLAGS snarfing code if and only if AC_CONFIG_MACRO_DIR_TRACE does not appear in the m4 traces. This solution will *only* work for Old Way (2) if AC_CONFIG_MACRO_DIR does *NOT* cause AC_CONFIG_MACRO_DIR_TRACE to appear in the m4 traces: i.e., this solution is incompatible with this patch to Autoconf. And for bonus points, notwithstanding any arguments that (3) and (4) are not worth caring about, this solution trivially maintains support for (3) and (4) anyway at no additional charge. [...] > 4. Upgrade everything, but don't rewrite configure.ac > Things continue to work as they have I don't believe this is the case. See above. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) From unknown Thu Sep 11 09:17:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#12845: [PATCH] AC_CONFIG_MACRO_DIRS: improve tracing and add sanity checks Resent-From: Eric Blake Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Tue, 13 Nov 2012 22:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12845 X-GNU-PR-Package: automake X-GNU-PR-Keywords: patch wontfix To: Nick Bowler Cc: autoconf-patches@gnu.org, Stefano Lattarini , 12845@debbugs.gnu.org, Adrian Bunk Received: via spool by 12845-submit@debbugs.gnu.org id=B12845.135284651320568 (code B ref 12845); Tue, 13 Nov 2012 22:42:01 +0000 Received: (at 12845) by debbugs.gnu.org; 13 Nov 2012 22:41:53 +0000 Received: from localhost ([127.0.0.1]:39688 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYPB2-0005Lg-Sy for submit@debbugs.gnu.org; Tue, 13 Nov 2012 17:41:53 -0500 Received: from mx1.redhat.com ([209.132.183.28]:2852) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYPAy-0005LV-HP for 12845@debbugs.gnu.org; Tue, 13 Nov 2012 17:41:50 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qADMfFkA032487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Nov 2012 17:41:15 -0500 Received: from [10.3.113.67] (ovpn-113-67.phx2.redhat.com [10.3.113.67]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qADMfEog026082; Tue, 13 Nov 2012 17:41:14 -0500 Message-ID: <50A2CC89.8060500@redhat.com> Date: Tue, 13 Nov 2012 15:41:13 -0700 From: Eric Blake Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 References: <20121112220112.GA1712@bunk.dyndns.info> <20121112221323.GA23877@elliptictech.com> <50A175F9.9090200@redhat.com> <20121112224129.GA24020@elliptictech.com> <20121112231213.GB1712@bunk.dyndns.info> <20121113143045.GA27271@elliptictech.com> <20121113185145.GA29576@bunk.dyndns.info> <20121113194408.GA26711@elliptictech.com> <50A2AAB2.4090200@gmail.com> <50A2AFF1.7010909@redhat.com> <20121113213538.GA13472@elliptictech.com> In-Reply-To: <20121113213538.GA13472@elliptictech.com> X-Enigmail-Version: 1.4.5 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigEE84111917177EFA897941FE" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Spam-Score: -5.2 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -7.1 (-------) This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEE84111917177EFA897941FE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/13/2012 02:35 PM, Nick Bowler wrote: > (0) Packages have a simple AC_CONFIG_MACRO_DIR([foo]) and a simple > ACLOCAL_AMFLAGS =3D -I foo and don't do anything weird. I think a= ll > of us agree that this is the most common case. Yep, and it works. >=20 > (1) Packages that use ACLOCAL_AMFLAGS to specify one or more macro > directories and do *NOT* use AC_CONFIG_MACRO_DIR at all. You > agreed earlier that this was a good choice for packages using > more than one macro directory. I suspect it's also quite common > in packages that aren't using libtool. For example, GNU Gettext > appears to be in this category. This will continue to work, although automake may start issuing warnings about ACLOCAL_AMFLAGS being deprecated. >=20 > (2) Packages that use a single AC_CONFIG_MACRO_DIR to only to shut up > libtool, and specify more than one macro directory in > ACLOCAL_AMFLAGS. You also agreed that this was a reasonable > choice for package maintainers who need more than one macro > directory. Reasonable, as long as the one directory they specify matches the first directory listed in ACLOCAL_AMFLAGS. Such packages can also add this to configure.ac: m4_define_default([AC_CONFIG_MACRO_DIRS]) AC_CONFIG_MACRO_DIRS([secondary]) to document the remaining directories in a manner that will work with autoconf 2.69. If anything, this would be a useful addition to autoconf NEWS. >=20 > (3) Packages that use more than one AC_CONFIG_MACRO_DIR. You argue > that this was broken to begin with. Correct. >=20 > (4) Packages that aren't using libtool, tried to do (0), but for > whatever reason AC_CONFIG_MACRO_DIR and ACLOCAL_AMFLAGS are out > of sync. You argue that this was broken to begin with. Correct. >=20 > For simplicity, let's only consider the following scenario: someone > wants to autoreconf an old package using new (as-yet-unreleased) > versions of Autoconf, Automake *AND* Libtool. >=20 > * With this patch to Autoconf, I'm not sure how anyone can possibly add= > support for AC_CONFIG_MACRO_DIR_TRACE to either aclocal or libtoolize= > without causing Old Way (2) to fail, without an absurd amount of extr= a > complexity and weird behaviour. With automake 1.14, the package as written will start triggering warnings in aclocal about ACLOCAL_AMFLAGS being obsolete, along with a suggestion to update configure.ac to use AC_CONFIG_MACRO_DIRS to specify the remaining directories. Automake 1.13 could even go one further by ensuring that m4_define_default([AC_CONFIG_MACRO_DIRS]) appears in the automake macro base, so that even if new automake is mixed with old autoconf, the advice to use AC_CONFIG_MACRO_DIRS won't cause any issues as long as the user sticks to new automake. The user can either ignore the warnings and make no change to their package (things will still work, just noisier), or heed the warnings and replace ACLOCAL_AMFLAGS with AC_CONFIG_MACRO_DIRS (a two-line cross-file change) - I don't see how this classes as an absurd amount of extra complexity and weird behavior. >=20 > * Maintaining support for both Old Ways (1) and (2) implies that > we cannot remove the ACLOCAL_AMFLAGS snarfing code from either > libtoolize or autoreconf. Actually, it is libtoolize and aclocal that care about ACLOCAL_AMFLAGS. autoreconf looks for it, but only insofar as it passes it on to aclocal; and if it is missing, then it is up to aclocal to diagnose any issues, not autoreconf. With new enough automake, it is not an issue. Yes, libtool and automake BOTH have to preserve support for ACLOCAL_AMFLAGS, at least as long as they aim to interoperate with autoconf 2.69 and older, but that is the burden on those two packages, and not the thousands of client packages that used the old interfaces correctly. >=20 > * Since we must keep the ACLOCAL_AMFLAGS snarfing code, it seems that > the easiest way to maintain support for Old Ways (0), (1) *AND* (2) i= s > to use the ACLOCAL_AMFLAGS snarfing code if and only if > AC_CONFIG_MACRO_DIR_TRACE does not appear in the m4 traces. > =20 > This solution will *only* work for Old Way (2) if AC_CONFIG_MACRO_DIR= > does *NOT* cause AC_CONFIG_MACRO_DIR_TRACE to appear in the m4 traces= : > i.e., this solution is incompatible with this patch to Autoconf. I disagree. Remember, condition (2) is that AC_CONFIG_MACRO_DIR and ACLOCAL_AMFLAGS agree on the primary directory, but that ACLOCAL_AMFLAGS had additional secondary directories that were not listed in configure.ac. If new automake sees AC_CONFIG_MACRO_DIR_TRACE, then it knows that new autoconf was in use; and can warn the user to add appropriate AC_CONFIG_MACRO_DIRS() to bring things back into sync before recommending that ACLOCAL_AMFLAGS be deleted. Either the user heeds that advice (possibly by using the m4_define_default trick to still preserve the ability to bootstrap their package with older autotools) or ignores it (and continues to get warnings about things being out of sync)= =2E But either way, it boils down to what automake does with the new macro, and not anything that autoconf needs to change. That is, until automake does AC_PREREQ([2.70]), it should ALWAYS check for ACLOCAL_AMFLAGS; and if present, it should do a sanity check whether the data that is supposed to be redundant between configure.ac and Makefile.am is actually redundant. If the data is out of sync, then the best course of action is to support the union of the two specifications, along with warning the user how to fix things. And if the data is in sync, warn the user that they can delete ACLOCAL_AMFLAGS. If ACLOCAL_AMFLAGS is absent, then AC_CONFIG_MACRO_DIR_TRACE is the sole source of correct information. >=20 > And for bonus points, notwithstanding any arguments that (3) and (4) > are not worth caring about, this solution trivially maintains support= > for (3) and (4) anyway at no additional charge. If I understand your argument correctly, you are claiming that AC_CONFIG_MACRO_DIR should _not_ trace into AC_CONFIG_MACRO_DIR_TRACE, so that case (2) can be distinguished by automake; but that would mean that automake has to trace _both_ AC_CONFIG_MACRO_DIR_TRACE and AC_CONFIG_MACRO_DIR for case (0) to work. But I'm arguing that since case (2) already implies that things are in sync, that merely comparing the trace against ACLOCAL_AMFLAGS is sufficient to tell if the user has updated their package, and if not, then ACLOCAL_AMFLAGS is still trusted for specifying secondary directories, as it has been done with older autotools. >=20 > [...] >> 4. Upgrade everything, but don't rewrite configure.ac >> Things continue to work as they have >=20 > I don't believe this is the case. See above. Only for case (3) and (4), but we agreed that those were already broken. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enigEE84111917177EFA897941FE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBCAAGBQJQosyJAAoJEKeha0olJ0NqBNAH/jNrrwHOslq63z8BZAj1CM1O Qc8B29VFlrsd45O93nddKfJxdTRUmcrkbtZZwH/ObaCM+FAGdmKf/DbBk348DEGT DzmLyY7OgKJHAkEws+4Qsd3egKmNMFgxOA4i15HJwDe2X5obnoaK18Bx1HoEbqAG 00zMOukkW3gcCxg8pmYF+kJY6ct4L6y4EbHXEbjJzjkB1vMoiTSGgxMdRqZ5igzG +fcdrqa3Oelz3WSiyHwTNwNjupVNnqMvj0GH9Za41uBQ49FLLfg6J0kRQ/fMAw9V fKTQlil8qSLvHahcdUXg+Lm4NQBakiKwwYNoFEVbKIir+W2unVDu5GOUnUmXBmI= =xKt8 -----END PGP SIGNATURE----- --------------enigEE84111917177EFA897941FE-- From unknown Thu Sep 11 09:17:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#12845: [PATCH] AC_CONFIG_MACRO_DIRS: improve tracing and add sanity checks Resent-From: Adrian Bunk Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Tue, 13 Nov 2012 22:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12845 X-GNU-PR-Package: automake X-GNU-PR-Keywords: patch wontfix To: Nick Bowler Cc: Stefano Lattarini , autoconf-patches@gnu.org, Eric Blake , 12845@debbugs.gnu.org Received: via spool by 12845-submit@debbugs.gnu.org id=B12845.135284746421910 (code B ref 12845); Tue, 13 Nov 2012 22:58:01 +0000 Received: (at 12845) by debbugs.gnu.org; 13 Nov 2012 22:57:44 +0000 Received: from localhost ([127.0.0.1]:39707 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYPQO-0005hL-4H for submit@debbugs.gnu.org; Tue, 13 Nov 2012 17:57:44 -0500 Received: from filtteri1.pp.htv.fi ([213.243.153.184]:53976) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYP96-0005IV-V4 for 12845@debbugs.gnu.org; Tue, 13 Nov 2012 17:39:55 -0500 Received: from localhost (localhost [127.0.0.1]) by filtteri1.pp.htv.fi (Postfix) with ESMTP id 9EDD921B55F; Wed, 14 Nov 2012 00:39:19 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from smtp5.welho.com ([213.243.153.39]) by localhost (filtteri1.pp.htv.fi [213.243.153.184]) (amavisd-new, port 10024) with ESMTP id 8HMTg3InuZKe; Wed, 14 Nov 2012 00:39:19 +0200 (EET) Received: from bunk.dyndns.info (cs185055.pp.htv.fi [213.243.185.55]) by smtp5.welho.com (Postfix) with ESMTP id 1B9BD5BC002; Wed, 14 Nov 2012 00:39:19 +0200 (EET) Date: Wed, 14 Nov 2012 00:39:11 +0200 From: Adrian Bunk Message-ID: <20121113223911.GC18928@bunk.dyndns.info> References: <20121112221323.GA23877@elliptictech.com> <50A175F9.9090200@redhat.com> <20121112224129.GA24020@elliptictech.com> <20121112231213.GB1712@bunk.dyndns.info> <20121113143045.GA27271@elliptictech.com> <20121113185145.GA29576@bunk.dyndns.info> <20121113194408.GA26711@elliptictech.com> <50A2AAB2.4090200@gmail.com> <50A2AFF1.7010909@redhat.com> <20121113213538.GA13472@elliptictech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20121113213538.GA13472@elliptictech.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: 0.8 (/) X-Mailman-Approved-At: Tue, 13 Nov 2012 17:57:42 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) On Tue, Nov 13, 2012 at 04:35:38PM -0500, Nick Bowler wrote: >... > (1) Packages that use ACLOCAL_AMFLAGS to specify one or more macro > directories and do *NOT* use AC_CONFIG_MACRO_DIR at all. You > agreed earlier that this was a good choice for packages using > more than one macro directory. I suspect it's also quite common > in packages that aren't using libtool. For example, GNU Gettext > appears to be in this category. >... Even libtoolize does not enforce AC_CONFIG_MACRO_DIR but just issues a warning when only ACLOCAL_AMFLAGS is present, so that might be present even in lintool-using packages with only one macro dir. I begin to agree with you that AC_CONFIG_MACRO_DIR should be left alone by autoconf, with the downside that removing support for the legacy ACLOCAL_AMFLAGS/AC_CONFIG_MACRO_DIR from aclocal or from libtoolize would not be reasonable to do within the next 5-10 years. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed From unknown Thu Sep 11 09:17:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#12845: [PATCH] AC_CONFIG_MACRO_DIRS: improve tracing and add sanity checks Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Wed, 14 Nov 2012 14:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12845 X-GNU-PR-Package: automake X-GNU-PR-Keywords: patch wontfix To: Eric Blake Cc: Nick Bowler , 12845@debbugs.gnu.org, autoconf-patches@gnu.org, Adrian Bunk Received: via spool by 12845-submit@debbugs.gnu.org id=B12845.135290411215116 (code B ref 12845); Wed, 14 Nov 2012 14:42:01 +0000 Received: (at 12845) by debbugs.gnu.org; 14 Nov 2012 14:41:52 +0000 Received: from localhost ([127.0.0.1]:41386 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYeA2-0003vh-Oo for submit@debbugs.gnu.org; Wed, 14 Nov 2012 09:41:51 -0500 Received: from mail-la0-f44.google.com ([209.85.215.44]:33913) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYe9y-0003vS-OW for 12845@debbugs.gnu.org; Wed, 14 Nov 2012 09:41:49 -0500 Received: by mail-la0-f44.google.com with SMTP id d3so425000lah.3 for <12845@debbugs.gnu.org>; Wed, 14 Nov 2012 06:41:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=UJo08q84bXfL+YX/oAr/PByGDVTYsrvvJyDS1ZT1BKk=; b=Y0n4oLKCvo4v8cLRhbEwNmQmOOAREyA1+lura2ml8KdP/zwvNDc5RLsapv2TY9Wwky ae8U5gEGFaQCiw4j6WjpqBaZt3OLnRLG+NdBw0TS8jwsvkMPzLV6ziE4xRq+l2PPEbBM sDUzDwtbgu/6/V13hN4RP1+50f9monjw2oKge3l1mcUFIbtNLwEr0LH8AjwezEzGZTFp QSwa8dYNDXhG1ocwaOfSZwhI+hSAQIxbRioMCI8ZWJB5qMJz8bZBzjB6VPRARcEyf81w 8iOpehhRGWiyVGUnvwZhZ8jd4+0/DEel97K+3AJriF44SXLtdp8kR64k3Bm0ZHA1HvFK SHeA== Received: by 10.152.144.69 with SMTP id sk5mr2094075lab.22.1352904069914; Wed, 14 Nov 2012 06:41:09 -0800 (PST) Received: from [192.168.178.21] (host247-100-dynamic.8-87-r.retail.telecomitalia.it. [87.8.100.247]) by mx.google.com with ESMTPS id oz12sm5119373lab.17.2012.11.14.06.41.07 (version=SSLv3 cipher=OTHER); Wed, 14 Nov 2012 06:41:08 -0800 (PST) Message-ID: <50A3AD81.2080103@gmail.com> Date: Wed, 14 Nov 2012 15:41:05 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <20121112220112.GA1712@bunk.dyndns.info> <20121112221323.GA23877@elliptictech.com> <50A175F9.9090200@redhat.com> <20121112224129.GA24020@elliptictech.com> <20121112231213.GB1712@bunk.dyndns.info> <20121113143045.GA27271@elliptictech.com> <20121113185145.GA29576@bunk.dyndns.info> <20121113194408.GA26711@elliptictech.com> <50A2AAB2.4090200@gmail.com> <50A2AFF1.7010909@redhat.com> <20121113213538.GA13472@elliptictech.com> <50A2CC89.8060500@redhat.com> In-Reply-To: <50A2CC89.8060500@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On 11/13/2012 11:41 PM, Eric Blake wrote: > > [SNIP] > >> (3) Packages that use more than one AC_CONFIG_MACRO_DIR. You argue >> that this was broken to begin with. > > Correct. > I agree. We don't want to support several calls to AC_CONFIG_MACRO_DIR, nor calls to AC_CONFIG_MACRO_DIR specifying more than one directory. That was never documented to be supported anyway. > [SNIP] >> >> For simplicity, let's only consider the following scenario: someone >> wants to autoreconf an old package using new (as-yet-unreleased) >> versions of Autoconf, Automake *AND* Libtool. >> >> * With this patch to Autoconf, I'm not sure how anyone can possibly add >> support for AC_CONFIG_MACRO_DIR_TRACE to either aclocal or libtoolize >> without causing Old Way (2) to fail, without an absurd amount of extra >> complexity and weird behaviour. > > With automake 1.14, the package as written will start triggering > warnings in aclocal about ACLOCAL_AMFLAGS being obsolete, along with a > suggestion to update configure.ac to use AC_CONFIG_MACRO_DIRS to specify > the remaining directories. Automake 1.13 could even go one further by > ensuring that m4_define_default([AC_CONFIG_MACRO_DIRS]) appears in the > automake macro base, so that even if new automake is mixed with old > autoconf, the advice to use AC_CONFIG_MACRO_DIRS won't cause any issues > as long as the user sticks to new automake. > That is a good idea. It could be put in 'm4/init.m4'. > The user can either ignore the warnings and make no change to their > package (things will still work, just noisier), or heed the warnings and > replace ACLOCAL_AMFLAGS with AC_CONFIG_MACRO_DIRS (a two-line cross-file > change) - I don't see how this classes as an absurd amount of extra > complexity and weird behavior. > >> >> * Maintaining support for both Old Ways (1) and (2) implies that >> we cannot remove the ACLOCAL_AMFLAGS snarfing code from either >> libtoolize or autoreconf. > > Actually, it is libtoolize and aclocal that care about ACLOCAL_AMFLAGS. > Nope, Nick was right: ACLOCAL_AMFLAGS is processed by autoreconf, but not by aclocal. So far, the only use of ACLOCAL_AMFLAGS in aclocal and automake has been in the automatic rebuild rules for aclocal.m4 (see 'lib/am/configure.am' in the Automake source tree). > autoreconf looks for it, but only insofar as it passes it on to > aclocal; > Ah, OK, so you knew it already. Unsurprising ;-) > and if it is missing, then it is up to aclocal to diagnose any > issues, not autoreconf. > I agree it's not autoreconf business to diagnose such issues; but neither is aclocal's. If anything, it should be automake that should do such diagnosis, since, as I've said, it's only automake generated rebuild rules that make use of ACLOCAL_AMFLAGS. > With new enough automake, it is not an issue. > > Yes, libtool and automake BOTH have to preserve support for > ACLOCAL_AMFLAGS, at least as long as they aim to interoperate with > autoconf 2.69 and older, but that is the burden on those two packages, > and not the thousands of client packages that used the old interfaces > correctly. > Agreed. >> >> * Since we must keep the ACLOCAL_AMFLAGS snarfing code, it seems that >> the easiest way to maintain support for Old Ways (0), (1) *AND* (2) is >> to use the ACLOCAL_AMFLAGS snarfing code if and only if >> AC_CONFIG_MACRO_DIR_TRACE does not appear in the m4 traces. >> >> This solution will *only* work for Old Way (2) if AC_CONFIG_MACRO_DIR >> does *NOT* cause AC_CONFIG_MACRO_DIR_TRACE to appear in the m4 traces: >> i.e., this solution is incompatible with this patch to Autoconf. > > I disagree. Remember, condition (2) is that AC_CONFIG_MACRO_DIR and > ACLOCAL_AMFLAGS agree on the primary directory, but that ACLOCAL_AMFLAGS > had additional secondary directories that were not listed in > configure.ac. If new automake sees AC_CONFIG_MACRO_DIR_TRACE, then it > knows that new autoconf was in use; and can warn the user to add > appropriate AC_CONFIG_MACRO_DIRS() to bring things back into sync before > recommending that ACLOCAL_AMFLAGS be deleted. Either the user heeds > that advice (possibly by using the m4_define_default trick to still > preserve the ability to bootstrap their package with older autotools) or > ignores it (and continues to get warnings about things being out of sync). > > But either way, it boils down to what automake does with the new macro, > and not anything that autoconf needs to change. That is, until automake > does AC_PREREQ([2.70]), it should ALWAYS check for ACLOCAL_AMFLAGS; and > if present, it should do a sanity check whether the data that is > supposed to be redundant between configure.ac and Makefile.am is > actually redundant. If the data is out of sync, then the best course of > action is to support the union of the two specifications, > That already happen automatically in the rebuild rules (with the directories in ACLOCAL_AMFLAGS taking precedence, as they end up being specified on the command line); and we get this for free, without any need to touch the pre-existing code. > along with warning the user how to fix things. > This is not yet implemented. > And if the data is in sync, warn the user that they can delete > ACLOCAL_AMFLAGS. > Unless they still use '--install' there. Making up for the removal of that will require tightening the "distcheck" rule; something for Automake 1.14. For more background, see: > If ACLOCAL_AMFLAGS is absent, then AC_CONFIG_MACRO_DIR_TRACE is > the sole source of correct information. > >> >> And for bonus points, notwithstanding any arguments that (3) and (4) >> are not worth caring about, this solution trivially maintains support >> for (3) and (4) anyway at no additional charge. > > If I understand your argument correctly, you are claiming that > AC_CONFIG_MACRO_DIR should _not_ trace into AC_CONFIG_MACRO_DIR_TRACE, > so that case (2) can be distinguished by automake; but that would mean > that automake has to trace _both_ AC_CONFIG_MACRO_DIR_TRACE and > AC_CONFIG_MACRO_DIR for case (0) to work. > Currently, Automake is already tracing both AC_CONFIG_MACRO_DIR and AC_CONFIG_MACRO_DIR_TRACE, to avoid several testsuite breakages. Are you arguing that tracing both macros is a bad idea? If yes, I might add in 'm4/init.m4' a (re)definition of the AC_CONFIG_MACRO_DIR and AC_CONFIG_MACRO_DIRS macros if pre-2.70 autoconf is detected, so that packages using older autoconf but newer aclocal/automake will still be able to rely on that macros. And this hack will be removed in Automake 1.14 (when we'll start requiring autoconf 2.70), so this clumsy extra code won't pollute our codebase for too long. Opinions? > But I'm arguing that since > case (2) already implies that things are in sync, that merely comparing > the trace against ACLOCAL_AMFLAGS is sufficient to tell if the user has > updated their package, and if not, then ACLOCAL_AMFLAGS is still trusted > for specifying secondary directories, as it has been done with older > autotools. > >> >> [...] >>> 4. Upgrade everything, but don't rewrite configure.ac >>> Things continue to work as they have >> >> I don't believe this is the case. See above. > > Only for case (3) and (4), but we agreed that those were already broken. > Regards, Stefano From unknown Thu Sep 11 09:17:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#12845: [PATCH] AC_CONFIG_MACRO_DIRS: improve tracing and add sanity checks Resent-From: Eric Blake Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Wed, 14 Nov 2012 14:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12845 X-GNU-PR-Package: automake X-GNU-PR-Keywords: patch wontfix To: Stefano Lattarini Cc: Nick Bowler , 12845@debbugs.gnu.org, autoconf-patches@gnu.org, Adrian Bunk Received: via spool by 12845-submit@debbugs.gnu.org id=B12845.135290469816541 (code B ref 12845); Wed, 14 Nov 2012 14:52:02 +0000 Received: (at 12845) by debbugs.gnu.org; 14 Nov 2012 14:51:38 +0000 Received: from localhost ([127.0.0.1]:41461 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYeJW-0004Ik-8j for submit@debbugs.gnu.org; Wed, 14 Nov 2012 09:51:38 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51837) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYeJS-0004IY-SA for 12845@debbugs.gnu.org; Wed, 14 Nov 2012 09:51:36 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qAEEovPo025875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Nov 2012 09:50:57 -0500 Received: from [10.3.113.23] (ovpn-113-23.phx2.redhat.com [10.3.113.23]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qAEEote6019795; Wed, 14 Nov 2012 09:50:56 -0500 Message-ID: <50A3AFCF.3070008@redhat.com> Date: Wed, 14 Nov 2012 07:50:55 -0700 From: Eric Blake Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 References: <20121112220112.GA1712@bunk.dyndns.info> <20121112221323.GA23877@elliptictech.com> <50A175F9.9090200@redhat.com> <20121112224129.GA24020@elliptictech.com> <20121112231213.GB1712@bunk.dyndns.info> <20121113143045.GA27271@elliptictech.com> <20121113185145.GA29576@bunk.dyndns.info> <20121113194408.GA26711@elliptictech.com> <50A2AAB2.4090200@gmail.com> <50A2AFF1.7010909@redhat.com> <20121113213538.GA13472@elliptictech.com> <50A2CC89.8060500@redhat.com> <50A3AD81.2080103@gmail.com> In-Reply-To: <50A3AD81.2080103@gmail.com> X-Enigmail-Version: 1.4.5 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig2AA8F032210725470B65ACAE" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Spam-Score: -4.4 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.2 (-----) This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2AA8F032210725470B65ACAE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/14/2012 07:41 AM, Stefano Lattarini wrote: >> If I understand your argument correctly, you are claiming that >> AC_CONFIG_MACRO_DIR should _not_ trace into AC_CONFIG_MACRO_DIR_TRACE,= >> so that case (2) can be distinguished by automake; but that would mean= >> that automake has to trace _both_ AC_CONFIG_MACRO_DIR_TRACE and >> AC_CONFIG_MACRO_DIR for case (0) to work. >> > Currently, Automake is already tracing both AC_CONFIG_MACRO_DIR and > AC_CONFIG_MACRO_DIR_TRACE, to avoid several testsuite breakages. Are > you arguing that tracing both macros is a bad idea? If yes, I might > add in 'm4/init.m4' a (re)definition of the AC_CONFIG_MACRO_DIR and > AC_CONFIG_MACRO_DIRS macros if pre-2.70 autoconf is detected, so that > packages using older autoconf but newer aclocal/automake will still be > able to rely on that macros. And this hack will be removed in Automake= > 1.14 (when we'll start requiring autoconf 2.70), so this clumsy extra > code won't pollute our codebase for too long. >=20 > Opinions? As long as you aim to interoperate with autoconf 2.69 but still diagnose mismatches between ACLOCAL_AMFLAGS on the primary directory [granted, the mistmatch diagnosis patch still needs to be written], then you have to trace AC_CONFIG_MACRO_DIR. However, you should only need to pay attention to the AC_CONFIG_MACRO_DIR trace in the case where AC_CONFIG_MACRO_DIR_TRACE had no hits (that is, only for older autoconf). On the other hand, it is harmless if, under newer autoconf, you pay attention to both macros - it just means that you will encounter the primary directory twice (once under each trace). As soon as you AC_PREREQ([2.70]), then yes, you can quit tracing AC_CONFIG_MACRO_DIR. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig2AA8F032210725470B65ACAE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBCAAGBQJQo6/PAAoJEKeha0olJ0NqLm0H/18J0O7JbAqXcgG4TiZKAiIK 9t+RAfZpbzUrAUI6nf7V90/1WU/Ny8LBgWxV8W8u/Yrpn4Q1dulLTeKu+lbSOrhT PQxQ7fLUbYW6c11rF0YWzZ3pOCfZdF62kutVXny2wo7iSNCC9+LTjAVuKQOYwPM2 4IJANN+Lrspb/SpzO6YWH+GOkFgmxzI/5Bry+pihqYuZM+XGX7BXOBWuj/mCOUbs MTp0rf/DGxmXsydIpJ90EJEqxVHgwNIt3BwOu5TjR4ouiBjg6X9YVdcCkLHWD7BT SSM9t0+EMnzL7t0Rb2QeJ/p3eWCasiAnZquEcLMJlgV8PhkpDB1moaT+ZY2ae3M= =OP7B -----END PGP SIGNATURE----- --------------enig2AA8F032210725470B65ACAE-- From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 14 09:53:30 2012 Received: (at control) by debbugs.gnu.org; 14 Nov 2012 14:53:30 +0000 Received: from localhost ([127.0.0.1]:41466 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYeLJ-0004Me-Tp for submit@debbugs.gnu.org; Wed, 14 Nov 2012 09:53:30 -0500 Received: from mail-lb0-f172.google.com ([209.85.217.172]:40415) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYeLH-0004MV-Ta for control@debbugs.gnu.org; Wed, 14 Nov 2012 09:53:28 -0500 Received: by mail-lb0-f172.google.com with SMTP id y2so503958lbk.3 for ; Wed, 14 Nov 2012 06:52:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:mime-version:to:subject:content-type :content-transfer-encoding; bh=Kv/fgwNbXYwkSmg73xMjOfrRuAH4ZEwijTn4cKGoWYM=; b=HL6Q1D4mKlpzWbda/OJ+7rmal7K68seSGYx8O6pLEuCE66+d4bD4XIuyZVw7VNucva PnQrjSnuIPdsyWN0OZ9fTjctm2eWy1y3fP5ZKp30ey5NVKkrdtHIYDOq6pLoV3TqBzUu aN19mFULk4Hb+huUg/rgmfEBMGEKZWaP+ogRbjqk1t2ONHVDNibcyWPsbT51dUWr+mdb 8lKR8ZT+xrk1IyOJZ8KX3VeduxmP27oO4ErM+/K1IRco/tv53zzaGeiuZUgeJT/A50Ra X+EEz+7uz7s3CGltdgmvASZt+1I+pMymNdtnSbsAjCvBVr+AIRgJMkcgBdu1g7dVCcBD hFOg== Received: by 10.112.39.225 with SMTP id s1mr2677009lbk.117.1352904771263; Wed, 14 Nov 2012 06:52:51 -0800 (PST) Received: from [192.168.178.21] (host247-100-dynamic.8-87-r.retail.telecomitalia.it. [87.8.100.247]) by mx.google.com with ESMTPS id sj3sm5140667lab.2.2012.11.14.06.52.49 (version=SSLv3 cipher=OTHER); Wed, 14 Nov 2012 06:52:50 -0800 (PST) Message-ID: <50A3B03E.7080500@gmail.com> Date: Wed, 14 Nov 2012 15:52:46 +0100 From: Stefano Lattarini MIME-Version: 1.0 To: GNU bug tracker automated control server Subject: x Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) tags 12845 - wontfix tags 12845 + moreinfo thanks From unknown Thu Sep 11 09:17:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#12845: [PATCH] AC_CONFIG_MACRO_DIRS: improve tracing and add sanity checks Resent-From: Nick Bowler Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Wed, 14 Nov 2012 22:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12845 X-GNU-PR-Package: automake X-GNU-PR-Keywords: moreinfo patch To: Eric Blake Cc: autoconf-patches@gnu.org, Stefano Lattarini , 12845@debbugs.gnu.org, Adrian Bunk Received: via spool by 12845-submit@debbugs.gnu.org id=B12845.135293160632389 (code B ref 12845); Wed, 14 Nov 2012 22:21:01 +0000 Received: (at 12845) by debbugs.gnu.org; 14 Nov 2012 22:20:06 +0000 Received: from localhost ([127.0.0.1]:42906 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYlJV-0008QL-NF for submit@debbugs.gnu.org; Wed, 14 Nov 2012 17:20:06 -0500 Received: from mx.scalarmail.ca ([98.158.95.75]:11240 helo=ironport-01.sms.scalar.ca) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYlJS-0008QD-Oa for 12845@debbugs.gnu.org; Wed, 14 Nov 2012 17:20:03 -0500 Received: from unknown (HELO sms-zimbra-mta-02.sms.scalar.ca) ([192.168.32.56]) by ironport-01.sms.scalar.ca with ESMTP; 14 Nov 2012 17:19:24 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by sms-zimbra-mta-02.sms.scalar.ca (Postfix) with ESMTP id B31F587BE0; Wed, 14 Nov 2012 17:19:24 -0500 (EST) Received: from sms-zimbra-mta-02.sms.scalar.ca ([127.0.0.1]) by localhost (sms-zimbra-mta-02.sms.scalar.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hyiu2CQ4IfPb; Wed, 14 Nov 2012 17:19:24 -0500 (EST) Received: from mail.ellipticsemi.com (mail.elliptictech.com [209.217.122.41]) (Authenticated sender: nbowler@elliptictech.com) by sms-zimbra-mta-02.sms.scalar.ca (Postfix) with ESMTPSA id BC9FC87C07; Wed, 14 Nov 2012 17:19:23 -0500 (EST) Date: Wed, 14 Nov 2012 17:19:23 -0500 From: Nick Bowler Message-ID: <20121114221922.GA32285@elliptictech.com> References: <50A175F9.9090200@redhat.com> <20121112224129.GA24020@elliptictech.com> <20121112231213.GB1712@bunk.dyndns.info> <20121113143045.GA27271@elliptictech.com> <20121113185145.GA29576@bunk.dyndns.info> <20121113194408.GA26711@elliptictech.com> <50A2AAB2.4090200@gmail.com> <50A2AFF1.7010909@redhat.com> <20121113213538.GA13472@elliptictech.com> <50A2CC89.8060500@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50A2CC89.8060500@redhat.com> Organization: Elliptic Technologies Inc. User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: 0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) On 2012-11-13 15:41 -0700, Eric Blake wrote: > On 11/13/2012 02:35 PM, Nick Bowler wrote: > > (0) Packages have a simple AC_CONFIG_MACRO_DIR([foo]) and a simple > > ACLOCAL_AMFLAGS = -I foo and don't do anything weird. [snipping all commentary on the list of cases] > > (1) Packages that use ACLOCAL_AMFLAGS to specify one or more macro > > directories and do *NOT* use AC_CONFIG_MACRO_DIR at all. [...] > > (2) Packages that use a single AC_CONFIG_MACRO_DIR to only to shut up > > libtool, and specify more than one macro directory in > > ACLOCAL_AMFLAGS. [...] > > (3) Packages that use more than one AC_CONFIG_MACRO_DIR. [...] > > (4) Packages that aren't using libtool, tried to do (0), but for > > whatever reason AC_CONFIG_MACRO_DIR and ACLOCAL_AMFLAGS are out > > of sync. You argue that this was broken to begin with. [...] > If I understand your argument correctly, you are claiming that > AC_CONFIG_MACRO_DIR should _not_ trace into AC_CONFIG_MACRO_DIR_TRACE, > so that case (2) can be distinguished by automake; Yes, exactly. > but that would mean that automake has to trace _both_ > AC_CONFIG_MACRO_DIR_TRACE and AC_CONFIG_MACRO_DIR for case (0) to > work. I don't think tracing AC_CONFIG_MACRO_DIR in case (0) would be necessary: it can be ignored since the appropriate directory will be picked up from ACLOCAL_AMFLAGS. > But I'm arguing that since case (2) already implies that things are in > sync, that merely comparing the trace against ACLOCAL_AMFLAGS is > sufficient to tell if the user has updated their package, and if not, > then ACLOCAL_AMFLAGS is still trusted for specifying secondary > directories, as it has been done with older autotools. So I'm willing to concede on case (3) as not being worth worrying about. Now that I've thought about it more, I think there's actually an even simpler solution, compatible with this patch, that will easily maintain backwards compatibility with cases (0), (1), (2). You won't even need to do any comparisons of the trace against ACLOCAL_AMFLAGS. It will also work with case (4) (OK, it will fail with some really contrived corner cases) if tools merely *warn* about garbage arguments to AC_CONFIG_MACRO_DIR instead of making it a fatal error. All that needs to happen, I think, is this: * aclocal looks for AC_CONFIG_MACRO_DIR_TRACE in the m4 traces, and unconditionally adds them to the macro search path. * aclocal ensures that any directories specified by -I options on the command line are searched *prior* to anything found in the m4 traces. This might actually be the current state of affairs, but I don't see anything in the Automake manual about the interaction between -I options and AC_CONFIG_MACRO_DIRS. * libtoolize uses the first AC_CONFIG_MACRO_DIR_TRACE if available, otherwise it falls back to snarfing ACLOCAL_AMFLAGS. and I think the rest is status quo: * autoreconf snarfs ACLOCAL_AMFLAGS and, if it's present, passes it to aclocal on the command line, just like it currently does. This is done unconditionally. * automake continues to emit rebuild rules which unconditionally reference $(ACLOCAL_AMFLAGS), just like it currently does. This should all work because in the cases we agree are important, (0), (1) and (2), the use of AC_CONFIG_MACRO_DIR is always redundant since the macro directory appears in the correct spot in ACLOCAL_AMFLAGS. And since there should be no harm in having the first macro directory appear more than once in the search path, nothing should break. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) From unknown Thu Sep 11 09:17:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#12845: [PATCH] aclocal: tracing AC_CONFIG_MACRO_DIRS can work with older autoconf as well (was: Re: bug#12845: [PATCH] AC_CONFIG_MACRO_DIRS: improve tracing and add sanity checks) Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Thu, 15 Nov 2012 11:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12845 X-GNU-PR-Package: automake X-GNU-PR-Keywords: moreinfo patch To: Eric Blake Cc: Nick Bowler , Autoconf Patches List , 12845@debbugs.gnu.org, "automake-patches@gnu.org" , Adrian Bunk Received: via spool by 12845-submit@debbugs.gnu.org id=B12845.13529771494786 (code B ref 12845); Thu, 15 Nov 2012 11:00:02 +0000 Received: (at 12845) by debbugs.gnu.org; 15 Nov 2012 10:59:09 +0000 Received: from localhost ([127.0.0.1]:44146 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYxA4-0001F8-Te for submit@debbugs.gnu.org; Thu, 15 Nov 2012 05:59:09 -0500 Received: from mail-lb0-f172.google.com ([209.85.217.172]:62982) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYxA0-0001Ey-EM for 12845@debbugs.gnu.org; Thu, 15 Nov 2012 05:59:07 -0500 Received: by mail-lb0-f172.google.com with SMTP id y2so1280992lbk.3 for <12845@debbugs.gnu.org>; Thu, 15 Nov 2012 02:58:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=58eMwGqeiIPOK6lc0rCJbPOwnxPZ5sJ5Xsa3oUpodZA=; b=twg9pvu4Diy1l/AOzNx1QLfE1g+8gBHYXsOe/KdbycQEtmyxI0MNAEYEhW9X29kkHD KPcUxrLA+DPrkiH0NCI9XSM+fefF4uh3+RGvI8HalOag+dEjnfpQVyNTLkFqR3jwguum 4D2tvVy6zoOZZwvYchN/I4kohOJ4qSUMgG3lVJi4k6P0BKcBX+V5odw+iW+/HwXy4sTY QJ3jX8sJ8pHLP36KKm0dfqMHpF2jEYUabMjiRpalvJcPGs61NVvJqrrSppIkYyN3sMxK jfYlXz/LrHO2Z2dV9UASbnxMVvcLWAkkDmeckM6esuIy5DAjxpOMj2Nb2XaVCX/+nwtT zxLQ== Received: by 10.112.41.163 with SMTP id g3mr439955lbl.79.1352977102564; Thu, 15 Nov 2012 02:58:22 -0800 (PST) Received: from [192.168.178.21] (host247-100-dynamic.8-87-r.retail.telecomitalia.it. [87.8.100.247]) by mx.google.com with ESMTPS id ti4sm6098204lab.1.2012.11.15.02.58.20 (version=SSLv3 cipher=OTHER); Thu, 15 Nov 2012 02:58:21 -0800 (PST) Message-ID: <50A4CACA.4090702@gmail.com> Date: Thu, 15 Nov 2012 11:58:18 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <20121112220112.GA1712@bunk.dyndns.info> <20121112221323.GA23877@elliptictech.com> <50A175F9.9090200@redhat.com> <20121112224129.GA24020@elliptictech.com> <20121112231213.GB1712@bunk.dyndns.info> <20121113143045.GA27271@elliptictech.com> <20121113185145.GA29576@bunk.dyndns.info> <20121113194408.GA26711@elliptictech.com> <50A2AAB2.4090200@gmail.com> <50A2AFF1.7010909@redhat.com> <20121113213538.GA13472@elliptictech.com> <50A2CC89.8060500@redhat.com> <50A3AD81.2080103@gmail.com> <50A3AFCF.3070008@redhat.com> In-Reply-To: <50A3AFCF.3070008@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) [+cc automake-patches] On 11/14/2012 03:50 PM, Eric Blake wrote: > On 11/14/2012 07:41 AM, Stefano Lattarini wrote: >>> If I understand your argument correctly, you are claiming that >>> AC_CONFIG_MACRO_DIR should _not_ trace into AC_CONFIG_MACRO_DIR_TRACE, >>> so that case (2) can be distinguished by automake; but that would mean >>> that automake has to trace _both_ AC_CONFIG_MACRO_DIR_TRACE and >>> AC_CONFIG_MACRO_DIR for case (0) to work. >>> >> Currently, Automake is already tracing both AC_CONFIG_MACRO_DIR and >> AC_CONFIG_MACRO_DIR_TRACE, to avoid several testsuite breakages. Are >> you arguing that tracing both macros is a bad idea? If yes, I might >> add in 'm4/init.m4' a (re)definition of the AC_CONFIG_MACRO_DIR and >> AC_CONFIG_MACRO_DIRS macros if pre-2.70 autoconf is detected, so that >> packages using older autoconf but newer aclocal/automake will still be >> able to rely on that macros. And this hack will be removed in Automake >> 1.14 (when we'll start requiring autoconf 2.70), so this clumsy extra >> code won't pollute our codebase for too long. >> >> Opinions? > > As long as you aim to interoperate with autoconf 2.69 but still diagnose > mismatches between ACLOCAL_AMFLAGS on the primary directory [granted, > the mistmatch diagnosis patch still needs to be written], then you have > to trace AC_CONFIG_MACRO_DIR. However, you should only need to pay > attention to the AC_CONFIG_MACRO_DIR trace in the case where > AC_CONFIG_MACRO_DIR_TRACE had no hits (that is, only for older > autoconf). On the other hand, it is harmless if, under newer autoconf, > you pay attention to both macros - it just means that you will encounter > the primary directory twice (once under each trace). > > As soon as you AC_PREREQ([2.70]), then yes, you can quit tracing > AC_CONFIG_MACRO_DIR. > The below patch should allow our users to employ AC_CONFIG_MACRO_DIRS with autoconf 2.69 as well. It still doesn't work with autoconf 2.68 and earlier though, due to a bug in autom4te option parsing (fixed by autoconf commit v2.68-120-gf4be358). That could be fixed by using an external file rather than stdin to pass aclocal the contents of '$ac_config_macro_dirs_fallback'; but I rather do so in a separate patch, with a dedicated rationale. So, OK to go? Regards, Stefano ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- >From a966b8bde5fe8bb4927ade875d80e057b4d3fa2f Mon Sep 17 00:00:00 2001 Message-Id: From: Stefano Lattarini Date: Wed, 14 Nov 2012 16:54:38 +0100 Subject: [PATCH] aclocal: tracing AC_CONFIG_MACRO_DIRS can work with older autoconf as well This will allow our users to interact also with pre-2.70 autoconf without need for the user to add ACLOCAL_AMFLAGS in Makefile.am. For example, before this change, in order to have aclocal look for macros in 'm4/dir1' and 'm4/dir2' also when (say) autoconf 2.69 was used, our users would have had to add something like: ACLOCAL_AMFLAGS = -I m4/dir1 -I m4/dir2 in Makefile.am, in addition to the AC_CONFIG_MACRO_DIRS([m4/dir1 m4/dir2]) in configure.ac. Now, the AC_CONFIG_MACRO_DIRS call is enough. See the long-winded discussion on automake bug#12845 for more details: * aclocal.in ($ac_config_macro_dirs_fallback): New global variable, contains m4 code to issue a fallback definition of AC_CONFIG_MACRO_DIRS as an alias for the private macro _AM_CONFIG_MACRO_DIRS. (trace_used_macros): Handle and trace that macro. Do some code reorganization and fix related botched indentation while at it. (write_aclocal): Output '$ac_config_macro_dirs_fallback' early in the generated aclocal.m4. * t/aclocal-macrodirs.tap: Run unconditionally, even with older autoconf. * t/subpkg-macrodir.sh: Likewise. * doc/automake.texi: Document only AC_CONFIG_MACRO_DIRS, rather than AC_CONFIG_MACRO_DIR. Signed-off-by: Stefano Lattarini --- aclocal.in | 53 ++++++++++++++++++++++++++++++++++++++----------- doc/automake.texi | 6 +++--- t/aclocal-macrodirs.tap | 6 ------ t/subpkg-macrodir.sh | 6 ------ 4 files changed, 44 insertions(+), 27 deletions(-) diff --git a/aclocal.in b/aclocal.in index d4e7000..3ee83c9 100644 --- a/aclocal.in +++ b/aclocal.in @@ -45,6 +45,16 @@ use File::Path (); # Some globals. +# Support AC_CONFIG_MACRO_DIRS also with older autoconf. +# FIXME: To be removed in Automake 1.14, once we can assume autoconf +# 2.70 or later. +# NOTE: This variable deliberately contain no newlines. +my $ac_config_macro_dirs_fallback = + "m4_ifndef([AC_CONFIG_MACRO_DIRS], [" . + "m4_defun([_AM_CONFIG_MACRO_DIRS], [])" . + "m4_defun([AC_CONFIG_MACRO_DIRS], [_AM_CONFIG_MACRO_DIRS(\$@)])" . + "])"; + # We do not operate in threaded mode. $perl_threads = 0; @@ -716,16 +726,23 @@ sub trace_used_macros () my %files = map { $map{$_} => 1 } keys %macro_seen; %files = strip_redundant_includes %files; - my $traces = ($ENV{AUTOM4TE} || '@am_AUTOM4TE@'); - $traces .= " --language Autoconf-without-aclocal-m4 "; + my $early_m4_code = ""; # When AC_CONFIG_MACRO_DIRS is used, avoid possible spurious warnings # from autom4te about macros being "m4_require'd but not m4_defun'd"; # for more background, see: # http://lists.gnu.org/archive/html/autoconf-patches/2012-11/msg00004.html # as well as autoconf commit 'v2.69-44-g1ed0548', "warn: allow aclocal # to silence m4_require warnings". - $traces = "echo 'm4_define([m4_require_silent_probe], [-])' | " . - "$traces - "; + $early_m4_code .= "m4_define([m4_require_silent_probe], [-])"; + # Support AC_CONFIG_MACRO_DIRS also with older autoconf. + # FIXME: To be removed in Automake 1.14, once we can assume autoconf + # 2.70 or later. + $early_m4_code .= $ac_config_macro_dirs_fallback; + + my $traces = ($ENV{AUTOM4TE} || '@am_AUTOM4TE@'); + $traces .= " --language Autoconf-without-aclocal-m4 "; + $traces = "echo '$early_m4_code' | $traces - "; + # All candidate files. $traces .= join (' ', (map { "'$_'" } @@ -738,11 +755,12 @@ sub trace_used_macros () 'AC_DEFUN_ONCE', 'AU_DEFUN', '_AM_AUTOCONF_VERSION', - # FIXME: We still need to trace AC_CONFIG_MACRO_DIR - # for compatibility with older autoconf. Remove this - # when we can assume Autoconf 2.70 or later. + 'AC_CONFIG_MACRO_DIR_TRACE', + # FIXME: This is an hack for compatibility with older + # autoconf. Remove this in Automake 1.14, when we can + # assume Autoconf 2.70 or later. 'AC_CONFIG_MACRO_DIR', - 'AC_CONFIG_MACRO_DIR_TRACE')), + '_AM_CONFIG_MACRO_DIRS')), # Do not trace $1 for all other macros as we do # not need it and it might contains harmful # characters (like newlines). @@ -776,18 +794,28 @@ sub trace_used_macros () { push @ac_config_macro_dirs, $arg1; } - # FIXME: We still need to trace AC_CONFIG_MACRO_DIR - # for compatibility with older autoconf. Remove this - # when we can assume Autoconf 2.70 or later. - elsif ($macro eq 'AC_CONFIG_MACRO_DIR') + # FIXME: We still need to trace AC_CONFIG_MACRO_DIR + # for compatibility with older autoconf. Remove this + # once we can assume Autoconf 2.70 or later. + elsif ($macro eq 'AC_CONFIG_MACRO_DIR') { @ac_config_macro_dirs = ($arg1); } + # FIXME:This is an hack for compatibility with older autoconf. + # Remove this once we can assume Autoconf 2.70 or later. + elsif ($macro eq '_AM_CONFIG_MACRO_DIRS') + { + # Empty leading/trailing fields might be produced by split, + # hence the grep is really needed. + push @ac_config_macro_dirs, grep (/./, (split /\s+/, $arg1)); + } } # FIXME: in Autoconf >= 2.70, AC_CONFIG_MACRO_DIR calls # AC_CONFIG_MACRO_DIR_TRACE behind the scenes, which could # leave unwanted duplicates in @ac_config_macro_dirs. + # Remove this in Automake 1.14, when we'll stop tracing + # AC_CONFIG_MACRO_DIR explicitly. @ac_config_macro_dirs = uniq @ac_config_macro_dirs; $tracefh->close; @@ -915,6 +943,7 @@ $output"; # even the implied warranty of MERCHANTABILITY or FITNESS FOR A # PARTICULAR PURPOSE. +$ac_config_macro_dirs_fallback $output"; # We try not to update $output_file unless necessary, because diff --git a/doc/automake.texi b/doc/automake.texi index 0118a21..c0b1abf 100644 --- a/doc/automake.texi +++ b/doc/automake.texi @@ -3605,10 +3605,10 @@ will be almost impossible to share macros between packages. The second possibility, which we do recommend, is to write each macro in its own file and gather all these files in a directory. This directory is usually called @file{m4/}. Then it's enough to update -@file{configure.ac} by adding a proper call to @code{AC_CONFIG_MACRO_DIR}: +@file{configure.ac} by adding a proper call to @code{AC_CONFIG_MACRO_DIRS}: @example -AC_CONFIG_MACRO_DIR([m4]) +AC_CONFIG_MACRO_DIRS([m4]) @end example @command{aclocal} will then take care of automatically adding @file{m4/} @@ -3731,7 +3731,7 @@ MyPackage uses an @file{m4/} directory to store local macros as explained in @ref{Local Macros}, and has @example -AC_CONFIG_MACRO_DIR([m4]) +AC_CONFIG_MACRO_DIRS([m4]) @end example @noindent diff --git a/t/aclocal-macrodirs.tap b/t/aclocal-macrodirs.tap index 28abb7c..0b6886b 100755 --- a/t/aclocal-macrodirs.tap +++ b/t/aclocal-macrodirs.tap @@ -20,12 +20,6 @@ am_create_testdir=empty . test-init.sh -{ $AUTOCONF -o /dev/null - < configure.ac <<'END' AC_INIT([super], [1.0]) AM_INIT_AUTOMAKE -- 1.8.0 From unknown Thu Sep 11 09:17:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#12845: [PATCH] aclocal: AC_CONFIG_MACRO_DIRS: work around autom4te option parsing bugs (was: Re: bug#12845: [PATCH] aclocal: tracing AC_CONFIG_MACRO_DIRS can work with older autoconf as well) Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Thu, 15 Nov 2012 11:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12845 X-GNU-PR-Package: automake X-GNU-PR-Keywords: moreinfo patch To: Eric Blake Cc: Nick Bowler , 12845@debbugs.gnu.org, Autoconf Patches List , "automake-patches@gnu.org" , Adrian Bunk Received: via spool by 12845-submit@debbugs.gnu.org id=B12845.135298042010064 (code B ref 12845); Thu, 15 Nov 2012 11:54:02 +0000 Received: (at 12845) by debbugs.gnu.org; 15 Nov 2012 11:53:40 +0000 Received: from localhost ([127.0.0.1]:44243 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYy0p-0002cG-GW for submit@debbugs.gnu.org; Thu, 15 Nov 2012 06:53:40 -0500 Received: from mail-lb0-f172.google.com ([209.85.217.172]:47662) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYy0n-0002c9-3q for 12845@debbugs.gnu.org; Thu, 15 Nov 2012 06:53:38 -0500 Received: by mail-lb0-f172.google.com with SMTP id y2so1314980lbk.3 for <12845@debbugs.gnu.org>; Thu, 15 Nov 2012 03:52:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=1NmIyIr2xOv25erCZbnKEyv+uRxzBxD6/AfMIsTGJsU=; b=02bpaDnn6RCdJq2/KP05lvxy62+X50QBynfczOyWmMQ4Vr81tryCEyZ2vOAXc0Ebw6 S4/mfLqTjZZfWwc6BxzuRYjDDolpWX+Knh2J/vvYfCeBIXR7yGP5pkoDzEKiNhxxDP76 9DAxSEJKZ1mfdSah/1MN40EFXy2cfDShiXDmnciHoLJ6QKRgC8TkjG6+Kxh293kO2Kyd GoFubLgDBSlsknA4PjDxsYyN+i49vdl8JNmRpl8GvYipGH4VQ1eU+npkS4ehnYpLDXVF MvI1LcYm6HWqHG0XWZeO2uS98lAuzLGLy77TkanRxJzDXeCXba/YJ3OtFsbslINkrl+w ZKpw== Received: by 10.112.47.226 with SMTP id g2mr514220lbn.32.1352980375333; Thu, 15 Nov 2012 03:52:55 -0800 (PST) Received: from [192.168.178.21] (host247-100-dynamic.8-87-r.retail.telecomitalia.it. [87.8.100.247]) by mx.google.com with ESMTPS id ew2sm6163298lbb.2.2012.11.15.03.52.53 (version=SSLv3 cipher=OTHER); Thu, 15 Nov 2012 03:52:54 -0800 (PST) Message-ID: <50A4D793.6030603@gmail.com> Date: Thu, 15 Nov 2012 12:52:51 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <20121112220112.GA1712@bunk.dyndns.info> <20121112221323.GA23877@elliptictech.com> <50A175F9.9090200@redhat.com> <20121112224129.GA24020@elliptictech.com> <20121112231213.GB1712@bunk.dyndns.info> <20121113143045.GA27271@elliptictech.com> <20121113185145.GA29576@bunk.dyndns.info> <20121113194408.GA26711@elliptictech.com> <50A2AAB2.4090200@gmail.com> <50A2AFF1.7010909@redhat.com> <20121113213538.GA13472@elliptictech.com> <50A2CC89.8060500@redhat.com> <50A3AD81.2080103@gmail.com> <50A3AFCF.3070008@redhat.com> <50A4CACA.4090702@gmail.com> In-Reply-To: <50A4CACA.4090702@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On 11/15/2012 11:58 AM, Stefano Lattarini wrote: > > The below patch should allow our users to employ AC_CONFIG_MACRO_DIRS > with autoconf 2.69 as well. It still doesn't work with autoconf 2.68 > and earlier though, due to a bug in autom4te option parsing (fixed by > autoconf commit v2.68-120-gf4be358). That could be fixed by using an > external file rather than stdin to pass aclocal the contents of > '$ac_config_macro_dirs_fallback'; but I rather do so in a separate > patch, with a dedicated rationale. > Done with the patch below. I'll push it (together with the earlier one) by this evening (CET). Regards, Stefano ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- >From a5cddc48e23a650c75f270dcb2e63d57ea3aa07b Mon Sep 17 00:00:00 2001 Message-Id: From: Stefano Lattarini Date: Thu, 15 Nov 2012 12:24:27 +0100 Subject: [PATCH] aclocal: AC_CONFIG_MACRO_DIRS: work around autom4te option parsing bugs The autom4te program coming with autoconf 2.68 and earlier had a bug which caused the "-" command line argument (with which we tell it to read some input from from standard input) to aways be pushed at the *end* of the command line, regardless of where the user specified it (that bug was fixed by autoconf commit 'v2.68-120-gf4be358', "getopt: new Autom4te::Getopt module"). This broken semantics conflict with our usage in aclocal, where we need to pass some input to the invoked autom4te program early, and have so far been using the stdin to do so. Now we start using an external file instead. * m4/internal/ac-config-macro-dirs.m4: New file, contain a fallback definition of the AC_CONFIG_MACRO_DIRS macro for older autoconf releases. * aclocal.in (trace_used_macros): When invoking autom4te, use that file instead of "abusing" standard input. * Makefile.am (dist_automake_ac_DATA): Rename ... (nobase_dist_automake_ac_DATA): ... like this. Add 'm4/internal/ac-config-macro-dirs.m4' to it. Signed-off-by: Stefano Lattarini --- Makefile.am | 3 ++- aclocal.in | 26 +++++++++++++++----------- m4/internal/ac-config-macro-dirs.m4 | 16 ++++++++++++++++ 3 files changed, 33 insertions(+), 12 deletions(-) create mode 100644 m4/internal/ac-config-macro-dirs.m4 diff --git a/Makefile.am b/Makefile.am index 065500f..34abc5a 100644 --- a/Makefile.am +++ b/Makefile.am @@ -255,7 +255,8 @@ dist_am_DATA = \ ## Automake-provided m4 macros. ## ## ------------------------------ ## -dist_automake_ac_DATA = \ +nobase_dist_automake_ac_DATA = \ + m4/internal/ac-config-macro-dirs.m4 \ m4/amversion.m4 \ m4/ar-lib.m4 \ m4/as.m4 \ diff --git a/aclocal.in b/aclocal.in index 3ee83c9..ce8ac5a 100644 --- a/aclocal.in +++ b/aclocal.in @@ -48,12 +48,12 @@ use File::Path (); # Support AC_CONFIG_MACRO_DIRS also with older autoconf. # FIXME: To be removed in Automake 1.14, once we can assume autoconf # 2.70 or later. -# NOTE: This variable deliberately contain no newlines. +# FIXME: keep in sync with 'internal/ac-config-macro-dirs.m4'. my $ac_config_macro_dirs_fallback = - "m4_ifndef([AC_CONFIG_MACRO_DIRS], [" . - "m4_defun([_AM_CONFIG_MACRO_DIRS], [])" . - "m4_defun([AC_CONFIG_MACRO_DIRS], [_AM_CONFIG_MACRO_DIRS(\$@)])" . - "])"; + 'm4_ifndef([AC_CONFIG_MACRO_DIRS], [' . + 'm4_defun([_AM_CONFIG_MACRO_DIRS], [])' . + 'm4_defun([AC_CONFIG_MACRO_DIRS], [_AM_CONFIG_MACRO_DIRS($@)])' . + '])'; # We do not operate in threaded mode. $perl_threads = 0; @@ -726,23 +726,27 @@ sub trace_used_macros () my %files = map { $map{$_} => 1 } keys %macro_seen; %files = strip_redundant_includes %files; - my $early_m4_code = ""; # When AC_CONFIG_MACRO_DIRS is used, avoid possible spurious warnings # from autom4te about macros being "m4_require'd but not m4_defun'd"; # for more background, see: # http://lists.gnu.org/archive/html/autoconf-patches/2012-11/msg00004.html # as well as autoconf commit 'v2.69-44-g1ed0548', "warn: allow aclocal # to silence m4_require warnings". - $early_m4_code .= "m4_define([m4_require_silent_probe], [-])"; - # Support AC_CONFIG_MACRO_DIRS also with older autoconf. - # FIXME: To be removed in Automake 1.14, once we can assume autoconf - # 2.70 or later. - $early_m4_code .= $ac_config_macro_dirs_fallback; + my $early_m4_code .= "m4_define([m4_require_silent_probe], [-])"; my $traces = ($ENV{AUTOM4TE} || '@am_AUTOM4TE@'); $traces .= " --language Autoconf-without-aclocal-m4 "; $traces = "echo '$early_m4_code' | $traces - "; + # Support AC_CONFIG_MACRO_DIRS also with older autoconf. + # Note that we can't use '$ac_config_macro_dirs_fallback' here, because + # a bug in option parsing code of autom4te 2.68 and earlier will cause + # it to read standard input last, even if the "-" argument is specified + # early. + # FIXME: To be removed in Automake 1.14, once we can assume autoconf + # 2.70 or later. + $traces .= "$automake_includes[0]/internal/ac-config-macro-dirs.m4 "; + # All candidate files. $traces .= join (' ', (map { "'$_'" } diff --git a/m4/internal/ac-config-macro-dirs.m4 b/m4/internal/ac-config-macro-dirs.m4 new file mode 100644 index 0000000..d6bd61d --- /dev/null +++ b/m4/internal/ac-config-macro-dirs.m4 @@ -0,0 +1,16 @@ +# Support AC_CONFIG_MACRO_DIRS with older autoconf. -*- Autoconf -*- +# FIXME: To be removed in Automake 1.14, once we can assume autoconf +# 2.70 or later. +# FIXME: keep ion sync with the contents of the variable +# '$ac_config_macro_dirs_fallback' in aclocal.in. + +# Copyright (C) 2012 Free Software Foundation, Inc. +# +# This file is free software; the Free Software Foundation +# gives unlimited permission to copy and/or distribute it, +# with or without modifications, as long as this notice is preserved. + +m4_ifndef([AC_CONFIG_MACRO_DIRS], [dnl + m4_defun([_AM_CONFIG_MACRO_DIRS], [])dnl + m4_defun([AC_CONFIG_MACRO_DIRS], [_AM_CONFIG_MACRO_DIRS($@)])dnl +]) -- 1.8.0 From unknown Thu Sep 11 09:17:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#12845: [PATCH] aclocal: AC_CONFIG_MACRO_DIRS: work around autom4te option parsing bugs Resent-From: Eric Blake Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Thu, 15 Nov 2012 12:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12845 X-GNU-PR-Package: automake X-GNU-PR-Keywords: moreinfo patch To: Stefano Lattarini Cc: Nick Bowler , 12845@debbugs.gnu.org, Autoconf Patches List , "automake-patches@gnu.org" , Adrian Bunk Received: via spool by 12845-submit@debbugs.gnu.org id=B12845.135298251913188 (code B ref 12845); Thu, 15 Nov 2012 12:29:01 +0000 Received: (at 12845) by debbugs.gnu.org; 15 Nov 2012 12:28:39 +0000 Received: from localhost ([127.0.0.1]:44287 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYyYf-0003QY-C5 for submit@debbugs.gnu.org; Thu, 15 Nov 2012 07:28:38 -0500 Received: from mx1.redhat.com ([209.132.183.28]:19005) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYyYc-0003QN-OQ for 12845@debbugs.gnu.org; Thu, 15 Nov 2012 07:28:36 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qAFCRo2a032305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Nov 2012 07:27:52 -0500 Received: from [10.3.113.23] (ovpn-113-23.phx2.redhat.com [10.3.113.23]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qAFCABuh018435; Thu, 15 Nov 2012 07:10:11 -0500 Message-ID: <50A4DBA2.6010306@redhat.com> Date: Thu, 15 Nov 2012 05:10:10 -0700 From: Eric Blake Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 References: <20121112220112.GA1712@bunk.dyndns.info> <20121112221323.GA23877@elliptictech.com> <50A175F9.9090200@redhat.com> <20121112224129.GA24020@elliptictech.com> <20121112231213.GB1712@bunk.dyndns.info> <20121113143045.GA27271@elliptictech.com> <20121113185145.GA29576@bunk.dyndns.info> <20121113194408.GA26711@elliptictech.com> <50A2AAB2.4090200@gmail.com> <50A2AFF1.7010909@redhat.com> <20121113213538.GA13472@elliptictech.com> <50A2CC89.8060500@redhat.com> <50A3AD81.2080103@gmail.com> <50A3AFCF.3070008@redhat.com> <50A4CACA.4090702@gmail.com> <50A4D793.6030603@gmail.com> In-Reply-To: <50A4D793.6030603@gmail.com> X-Enigmail-Version: 1.4.5 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig726A2B5691B4D21D14F516AE" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Spam-Score: -5.1 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -7.0 (-------) This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig726A2B5691B4D21D14F516AE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/15/2012 04:52 AM, Stefano Lattarini wrote: > On 11/15/2012 11:58 AM, Stefano Lattarini wrote: >> >> The below patch should allow our users to employ AC_CONFIG_MACRO_DIRS >> with autoconf 2.69 as well. It still doesn't work with autoconf 2.68 >> and earlier though, due to a bug in autom4te option parsing (fixed by >> autoconf commit v2.68-120-gf4be358). That could be fixed by using an >> external file rather than stdin to pass aclocal the contents of >> '$ac_config_macro_dirs_fallback'; but I rather do so in a separate >> patch, with a dedicated rationale. >> > Done with the patch below. I'll push it (together with the earlier one= ) > by this evening (CET). >=20 > +++ b/m4/internal/ac-config-macro-dirs.m4 > @@ -0,0 +1,16 @@ > +# Support AC_CONFIG_MACRO_DIRS with older autoconf. -*- Autoconf -= *- > +# FIXME: To be removed in Automake 1.14, once we can assume autoconf > +# 2.70 or later. > +# FIXME: keep ion sync with the contents of the variable s/ion/in/ > +# '$ac_config_macro_dirs_fallback' in aclocal.in. > + > +# Copyright (C) 2012 Free Software Foundation, Inc. > +# > +# This file is free software; the Free Software Foundation > +# gives unlimited permission to copy and/or distribute it, > +# with or without modifications, as long as this notice is preserved. > + > +m4_ifndef([AC_CONFIG_MACRO_DIRS], [dnl > + m4_defun([_AM_CONFIG_MACRO_DIRS], [])dnl > + m4_defun([AC_CONFIG_MACRO_DIRS], [_AM_CONFIG_MACRO_DIRS($@)])dnl > +]) Hmm - this version is slightly different than the perl version it is replacing. Each use of AC_CONFIG_MACRO_DIRS now injects whitespace (6 spaces) into the user's configure script, then ignores the rest of the line (or worse, changes the rest of the line). That is, if the user writes: AC_CONFIG_MACRO_DIRS([a])AC_CONFIG_MACRO_DIRS([b]) the perl version transforms it into the empty string with two trace calls, but this version transforms it into: dnlAC_CONFIG_MACRO_DIRS([b]) and only traces 'a'. Here's how I would fix it (using the style I use in autoconf): m4_ifndef([AC_CONFIG_MACRO_DIRS], [m4_defun([_AM_CONFIG_MACRO_DIRS])]dnl [m4_defun([AC_CONFIG_MACRO_DIRS], [_AM_CONFIG_MACRO_DIRS($@)])]) --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig726A2B5691B4D21D14F516AE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBCAAGBQJQpNuiAAoJEKeha0olJ0NqqbAIAK9xd2w3hL6+UIoTvOfybbZl h18Lvz38G03FgAZCmC5uVROmUiZJYoJ4Osskwngabvwrns0i6W82NhKGx/Ksvf0a +Cb6ClRxO2xiX0CJ2GNhPynvLXP1ymNKa9I9f6ErtfYcj+UrDO3NGDMOPPCdQhdn YC1u7wOP+bLbye5XxDCpRzKlFJcaJ6CyoLxG1w0lLQ/UfAg+o/KZB0IYLEfpAOJI tw1h2H2Kip2b8Ns6NWE3d/HU5rAkhyd/ews9pJzk2jQMDy1EfB4YgV1KnKRKPIjx 7WaSUow9MV9K45PK6RafmcAH5RtiDn0BUtZz0qOQTRMUnsYhZVWQX1Ff6IQ1ksE= =k0T7 -----END PGP SIGNATURE----- --------------enig726A2B5691B4D21D14F516AE-- From unknown Thu Sep 11 09:17:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#12845: [PATCH] aclocal: tracing AC_CONFIG_MACRO_DIRS can work with older autoconf as well Resent-From: Eric Blake Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Thu, 15 Nov 2012 12:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12845 X-GNU-PR-Package: automake X-GNU-PR-Keywords: moreinfo patch To: Stefano Lattarini Cc: Nick Bowler , Autoconf Patches List , 12845@debbugs.gnu.org, "automake-patches@gnu.org" , Adrian Bunk Received: via spool by 12845-submit@debbugs.gnu.org id=B12845.135298252013197 (code B ref 12845); Thu, 15 Nov 2012 12:29:02 +0000 Received: (at 12845) by debbugs.gnu.org; 15 Nov 2012 12:28:40 +0000 Received: from localhost ([127.0.0.1]:44289 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYyYi-0003Qn-73 for submit@debbugs.gnu.org; Thu, 15 Nov 2012 07:28:40 -0500 Received: from mx1.redhat.com ([209.132.183.28]:16517) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYyYc-0003QO-OS for 12845@debbugs.gnu.org; Thu, 15 Nov 2012 07:28:38 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qAFCRo2c032305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Nov 2012 07:27:52 -0500 Received: from [10.3.113.23] (ovpn-113-23.phx2.redhat.com [10.3.113.23]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qAFC0aLA016384; Thu, 15 Nov 2012 07:00:48 -0500 Message-ID: <50A4D963.2080101@redhat.com> Date: Thu, 15 Nov 2012 05:00:35 -0700 From: Eric Blake Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 References: <20121112220112.GA1712@bunk.dyndns.info> <20121112221323.GA23877@elliptictech.com> <50A175F9.9090200@redhat.com> <20121112224129.GA24020@elliptictech.com> <20121112231213.GB1712@bunk.dyndns.info> <20121113143045.GA27271@elliptictech.com> <20121113185145.GA29576@bunk.dyndns.info> <20121113194408.GA26711@elliptictech.com> <50A2AAB2.4090200@gmail.com> <50A2AFF1.7010909@redhat.com> <20121113213538.GA13472@elliptictech.com> <50A2CC89.8060500@redhat.com> <50A3AD81.2080103@gmail.com> <50A3AFCF.3070008@redhat.com> <50A4CACA.4090702@gmail.com> In-Reply-To: <50A4CACA.4090702@gmail.com> X-Enigmail-Version: 1.4.5 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigE08393EE617C78A6B7B80DF4" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Spam-Score: -7.0 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -7.0 (-------) This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE08393EE617C78A6B7B80DF4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/15/2012 03:58 AM, Stefano Lattarini wrote: >> As soon as you AC_PREREQ([2.70]), then yes, you can quit tracing >> AC_CONFIG_MACRO_DIR. >> > The below patch should allow our users to employ AC_CONFIG_MACRO_DIRS > with autoconf 2.69 as well. It still doesn't work with autoconf 2.68 > and earlier though, due to a bug in autom4te option parsing (fixed by > autoconf commit v2.68-120-gf4be358). That could be fixed by using an > external file rather than stdin to pass aclocal the contents of > '$ac_config_macro_dirs_fallback'; but I rather do so in a separate > patch, with a dedicated rationale. Yes, splitting that into a separate patch makes sense. > * aclocal.in ($ac_config_macro_dirs_fallback): New global variable, > contains m4 code to issue a fallback definition of AC_CONFIG_MACRO_DIRS= > as an alias for the private macro _AM_CONFIG_MACRO_DIRS. Tracing a new private macro - doesn't this imply that autoconf needs to add another macro to its list of preselections in order to pass the autoconf testsuite when using the new automake? But don't let that stop this patch. > +++ b/aclocal.in > @@ -45,6 +45,16 @@ use File::Path (); >=20 > # Some globals. >=20 > +# Support AC_CONFIG_MACRO_DIRS also with older autoconf. > +# FIXME: To be removed in Automake 1.14, once we can assume autoconf > +# 2.70 or later. > +# NOTE: This variable deliberately contain no newlines. > +my $ac_config_macro_dirs_fallback =3D > + "m4_ifndef([AC_CONFIG_MACRO_DIRS], [" . > + "m4_defun([_AM_CONFIG_MACRO_DIRS], [])" . > + "m4_defun([AC_CONFIG_MACRO_DIRS], [_AM_CONFIG_MACRO_DIRS(\$@)])" .= > + "])"; Hmm. Packages that want to work with automake 1.12 and autoconf 2.69, but still use AC_CONFIG_MACRO_DIRS, may have also added a conditional definition of AC_CONFIG_MACRO_DIRS in their configure.ac. But it turns out that you are injecting this snippet after m4sugar definitions (so m4_ifndef works) but before configure.ac, so your definition will take precedence. Yep - that works :) > + > # We do not operate in threaded mode. > $perl_threads =3D 0; >=20 > @@ -716,16 +726,23 @@ sub trace_used_macros () > my %files =3D map { $map{$_} =3D> 1 } keys %macro_seen; > %files =3D strip_redundant_includes %files; >=20 > - my $traces =3D ($ENV{AUTOM4TE} || '@am_AUTOM4TE@'); > - $traces .=3D " --language Autoconf-without-aclocal-m4 "; > + my $early_m4_code =3D ""; > # When AC_CONFIG_MACRO_DIRS is used, avoid possible spurious warning= s > # from autom4te about macros being "m4_require'd but not m4_defun'd"= ; > # for more background, see: > # http://lists.gnu.org/archive/html/autoconf-patches/2012-11/msg0000= 4.html > # as well as autoconf commit 'v2.69-44-g1ed0548', "warn: allow acloc= al > # to silence m4_require warnings". > - $traces =3D "echo 'm4_define([m4_require_silent_probe], [-])' | " . > - "$traces - "; > + $early_m4_code .=3D "m4_define([m4_require_silent_probe], [-])"; > + # Support AC_CONFIG_MACRO_DIRS also with older autoconf. > + # FIXME: To be removed in Automake 1.14, once we can assume autoconf= > + # 2.70 or later. > + $early_m4_code .=3D $ac_config_macro_dirs_fallback; If you are adding a fallback for AC_CONFIG_MACRO_DIRS when running aclocal, you'll also need to add that fallback when running automake. (But reading further, it looks like you did.) > @@ -738,11 +755,12 @@ sub trace_used_macros () > 'AC_DEFUN_ONCE', > 'AU_DEFUN', > '_AM_AUTOCONF_VERSION', > - # FIXME: We still need to trace AC_CONFIG_MACRO_DIR > - # for compatibility with older autoconf. Remove = this > - # when we can assume Autoconf 2.70 or later. > + 'AC_CONFIG_MACRO_DIR_TRACE', > + # FIXME: This is an hack for compatibility with o= lder s/an hack/a hack/ - use 'a' before a pronounced 'h', 'an' before a silent 'h'. > + # autoconf. Remove this in Automake 1.14, when w= e can > + # assume Autoconf 2.70 or later. > 'AC_CONFIG_MACRO_DIR', > - 'AC_CONFIG_MACRO_DIR_TRACE')), > + '_AM_CONFIG_MACRO_DIRS')), Isn't it really: "These next two variables are a hack" > +++ b/doc/automake.texi > @@ -3605,10 +3605,10 @@ will be almost impossible to share macros betwe= en packages. > The second possibility, which we do recommend, is to write each macro > in its own file and gather all these files in a directory. This > directory is usually called @file{m4/}. Then it's enough to update > -@file{configure.ac} by adding a proper call to @code{AC_CONFIG_MACRO_D= IR}: > +@file{configure.ac} by adding a proper call to @code{AC_CONFIG_MACRO_D= IRS}: >=20 > @example > -AC_CONFIG_MACRO_DIR([m4]) > +AC_CONFIG_MACRO_DIRS([m4]) > @end example >=20 > @command{aclocal} will then take care of automatically adding @file{m4= /} > @@ -3731,7 +3731,7 @@ MyPackage uses an @file{m4/} directory to store l= ocal macros as > explained in @ref{Local Macros}, and has >=20 > @example > -AC_CONFIG_MACRO_DIR([m4]) > +AC_CONFIG_MACRO_DIRS([m4]) > @end example It _might_ be worth mentioning that you must use one or both of automake 1.13 or autoconf 2.70 to have this work, and that back-compat to automake 1.12 and autoconf 2.69 requires manual effort in configure.ac. Meanwhile, I ought to do the same in the autoconf manual. ACK once you fix the comment. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enigE08393EE617C78A6B7B80DF4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBCAAGBQJQpNljAAoJEKeha0olJ0NqweEH/jqmRxapn6W1Z/Ja7BWIwImE YIrZ3GtmpomrrKhZVecQoECz3zefmii56LbfE2XaRchHJiewqb3Gt7CzugRenlbr Y21nFvv0nwzH96JDo5wB6CYg/oi4pGaa752gh3L9vtuwsjNGRdf6TX/fA2yZHRum HnqcEXPVOCTcA3i1croFi+IB/ufUKpHpoiblOh/ZiBU0XULjpMBsifd90MIbOrnL aS6u5wb3NGN2lDsXdm5yVOugUnEJRppUZUGyfj3SJkA7a1AjX7pwdCfKnoiKzfFy 0a+Om9pSFHXkG9HqYvhMn7hw8pUFAsGTRDeNspAA8bGBmHYAaJrN8KaFjnVoRJE= =KKzu -----END PGP SIGNATURE----- --------------enigE08393EE617C78A6B7B80DF4-- From unknown Thu Sep 11 09:17:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#12845: [PATCH] aclocal: AC_CONFIG_MACRO_DIRS: work around autom4te option parsing bugs Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Thu, 15 Nov 2012 12:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12845 X-GNU-PR-Package: automake X-GNU-PR-Keywords: moreinfo patch To: Eric Blake Cc: Nick Bowler , 12845@debbugs.gnu.org, Autoconf Patches List , "automake-patches@gnu.org" , Adrian Bunk Received: via spool by 12845-submit@debbugs.gnu.org id=B12845.135298296717210 (code B ref 12845); Thu, 15 Nov 2012 12:37:02 +0000 Received: (at 12845) by debbugs.gnu.org; 15 Nov 2012 12:36:07 +0000 Received: from localhost ([127.0.0.1]:44309 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYyfu-0004TW-Pm for submit@debbugs.gnu.org; Thu, 15 Nov 2012 07:36:07 -0500 Received: from mail-bk0-f44.google.com ([209.85.214.44]:64829) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYyfs-0004TP-5Z for 12845@debbugs.gnu.org; Thu, 15 Nov 2012 07:36:05 -0500 Received: by mail-bk0-f44.google.com with SMTP id w11so707542bku.3 for <12845@debbugs.gnu.org>; Thu, 15 Nov 2012 04:35:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=l4ormrdhIannm29WFTWQSjzjQCBhDStXU2o7jqZ6KcU=; b=Y9t928zq1qHzbqiyxE1R3/k0duBjsiaAu0acz5wK4a+e1mI2/jKlBoxr/QAn8FzOmb T6Usbv1PtxagzMnrXB9l+vSbixe197uM/px9qDbgjjFcWX6Gko6pfLq8cc3ZgUXQf7De sBPUkz9KsQL84B6/N/5uC9VgIIbb9ZWRxjnMAUj8YVB/J2VsfJ/fdrscJdTjvUPW8+rd vLH2C1Hfc6IHXo3bpv4Jy4gSW8VxfhDl6eYxleTkqFCUoIZHx/lOAdAyLpf4ZkdOcs2S ec7H0085Q+QYSuJAvLiZUEt8FYlueaPlwOZN38G2xMWS4qf/KY13McM7Np7R5SfJcoFS KLDQ== Received: by 10.204.9.3 with SMTP id j3mr310819bkj.134.1352982922394; Thu, 15 Nov 2012 04:35:22 -0800 (PST) Received: from [192.168.178.21] (host247-100-dynamic.8-87-r.retail.telecomitalia.it. [87.8.100.247]) by mx.google.com with ESMTPS id k21sm10082756bkv.1.2012.11.15.04.35.19 (version=SSLv3 cipher=OTHER); Thu, 15 Nov 2012 04:35:21 -0800 (PST) Message-ID: <50A4E185.1020703@gmail.com> Date: Thu, 15 Nov 2012 13:35:17 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <20121112220112.GA1712@bunk.dyndns.info> <20121112221323.GA23877@elliptictech.com> <50A175F9.9090200@redhat.com> <20121112224129.GA24020@elliptictech.com> <20121112231213.GB1712@bunk.dyndns.info> <20121113143045.GA27271@elliptictech.com> <20121113185145.GA29576@bunk.dyndns.info> <20121113194408.GA26711@elliptictech.com> <50A2AAB2.4090200@gmail.com> <50A2AFF1.7010909@redhat.com> <20121113213538.GA13472@elliptictech.com> <50A2CC89.8060500@redhat.com> <50A3AD81.2080103@gmail.com> <50A3AFCF.3070008@redhat.com> <50A4CACA.4090702@gmail.com> <50A4D793.6030603@gmail.com> <50A4DBA2.6010306@redhat.com> In-Reply-To: <50A4DBA2.6010306@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Hi Eric, thanks for the quick feedback. First of all, I've noticed this squash-in is necessary to avoid a spurious testsuite failure: diff --git a/t/aclocal-acdir.sh b/t/aclocal-acdir.sh index 59182bb..944604b 100755 --- a/t/aclocal-acdir.sh +++ b/t/aclocal-acdir.sh @@ -21,6 +21,9 @@ . test-init.sh mkdir am sys +# FIXME: remove in Automake 1.14. +mkdir am/internal +: > am/internal/ac-config-macro-dirs.m4 cat >> configure.ac <<'END' MY_MACRO Now let's come to your nits ... On 11/15/2012 01:10 PM, Eric Blake wrote: > On 11/15/2012 04:52 AM, Stefano Lattarini wrote: >> On 11/15/2012 11:58 AM, Stefano Lattarini wrote: >>> >>> The below patch should allow our users to employ AC_CONFIG_MACRO_DIRS >>> with autoconf 2.69 as well. It still doesn't work with autoconf 2.68 >>> and earlier though, due to a bug in autom4te option parsing (fixed by >>> autoconf commit v2.68-120-gf4be358). That could be fixed by using an >>> external file rather than stdin to pass aclocal the contents of >>> '$ac_config_macro_dirs_fallback'; but I rather do so in a separate >>> patch, with a dedicated rationale. >>> >> Done with the patch below. I'll push it (together with the earlier one) >> by this evening (CET). >> > >> +++ b/m4/internal/ac-config-macro-dirs.m4 >> @@ -0,0 +1,16 @@ >> +# Support AC_CONFIG_MACRO_DIRS with older autoconf. -*- Autoconf -*- >> +# FIXME: To be removed in Automake 1.14, once we can assume autoconf >> +# 2.70 or later. >> +# FIXME: keep ion sync with the contents of the variable > > s/ion/in/ > Fixed, thanks. >> +# '$ac_config_macro_dirs_fallback' in aclocal.in. >> + >> +# Copyright (C) 2012 Free Software Foundation, Inc. >> +# >> +# This file is free software; the Free Software Foundation >> +# gives unlimited permission to copy and/or distribute it, >> +# with or without modifications, as long as this notice is preserved. >> + >> +m4_ifndef([AC_CONFIG_MACRO_DIRS], [dnl >> + m4_defun([_AM_CONFIG_MACRO_DIRS], [])dnl >> + m4_defun([AC_CONFIG_MACRO_DIRS], [_AM_CONFIG_MACRO_DIRS($@)])dnl >> +]) > > Hmm - this version is slightly different than the perl version it is > replacing. Each use of AC_CONFIG_MACRO_DIRS now injects whitespace (6 > spaces) into the user's configure script, then ignores the rest of the > line (or worse, changes the rest of the line). > > That is, if the user writes: > > AC_CONFIG_MACRO_DIRS([a])AC_CONFIG_MACRO_DIRS([b]) > > the perl version transforms it into the empty string with two trace > calls, but this version transforms it into: > dnlAC_CONFIG_MACRO_DIRS([b]) > and only traces 'a'. Here's how I would fix it (using the style I use > in autoconf): > > m4_ifndef([AC_CONFIG_MACRO_DIRS], > [m4_defun([_AM_CONFIG_MACRO_DIRS])]dnl > [m4_defun([AC_CONFIG_MACRO_DIRS], [_AM_CONFIG_MACRO_DIRS($@)])]) > Thanks for catching this issue. I've amended my patch to follow your advice. I've also added: Helped-by: Eric Blake to the commit message. Best regards, Stefano From unknown Thu Sep 11 09:17:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#12845: [PATCH] aclocal: tracing AC_CONFIG_MACRO_DIRS can work with older autoconf as well Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Thu, 15 Nov 2012 12:48:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12845 X-GNU-PR-Package: automake X-GNU-PR-Keywords: moreinfo patch To: Eric Blake Cc: Nick Bowler , 12845@debbugs.gnu.org, Autoconf Patches List , "automake-patches@gnu.org" , Adrian Bunk Received: via spool by 12845-submit@debbugs.gnu.org id=B12845.135298366618202 (code B ref 12845); Thu, 15 Nov 2012 12:48:01 +0000 Received: (at 12845) by debbugs.gnu.org; 15 Nov 2012 12:47:46 +0000 Received: from localhost ([127.0.0.1]:44316 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYyrB-0004jW-F6 for submit@debbugs.gnu.org; Thu, 15 Nov 2012 07:47:46 -0500 Received: from mail-lb0-f172.google.com ([209.85.217.172]:59381) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYyr8-0004jO-V5 for 12845@debbugs.gnu.org; Thu, 15 Nov 2012 07:47:44 -0500 Received: by mail-lb0-f172.google.com with SMTP id y2so1350319lbk.3 for <12845@debbugs.gnu.org>; Thu, 15 Nov 2012 04:47:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=q+7IzhigX4+JoxrevieuiD9j289CyR8n7wuS9jWK3kw=; b=xvhJ9No0G/8yeV1MFjwXlZwL19qf2wEYKHMEE+QGbh36Yjs+dXfnhzBuCBD+Xd1vEN k10qJoamd9quCX0vy5NE9lKIy1iIFZ8qlNvPQAdlHiCmSgM3GIRusNMai9B3s8RDz8gC xvVBlTiJRpLiJd3t3gVcDwKXVyMsP0QoV5Uu9q/gDcsW5G87n1fYlMKPEOgq8HQhyRKL TklB9Xjflt9TOQTmGPtE9FRDbMZIj4R/jgD+AwrfUDihq6Zv9CKtfyE/FHQOFUC/yZdw 59xdIRnqrhESDLchF7vkdoSOW2jXUAVly5iHedb0eoEEho6VV1WhGQ/g4zem9Gg1tS5n ekOA== Received: by 10.112.30.137 with SMTP id s9mr581089lbh.0.1352983621045; Thu, 15 Nov 2012 04:47:01 -0800 (PST) Received: from [192.168.178.21] (host247-100-dynamic.8-87-r.retail.telecomitalia.it. [87.8.100.247]) by mx.google.com with ESMTPS id m3sm6214784lbb.13.2012.11.15.04.46.58 (version=SSLv3 cipher=OTHER); Thu, 15 Nov 2012 04:47:00 -0800 (PST) Message-ID: <50A4E440.2040903@gmail.com> Date: Thu, 15 Nov 2012 13:46:56 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <20121112220112.GA1712@bunk.dyndns.info> <20121112221323.GA23877@elliptictech.com> <50A175F9.9090200@redhat.com> <20121112224129.GA24020@elliptictech.com> <20121112231213.GB1712@bunk.dyndns.info> <20121113143045.GA27271@elliptictech.com> <20121113185145.GA29576@bunk.dyndns.info> <20121113194408.GA26711@elliptictech.com> <50A2AAB2.4090200@gmail.com> <50A2AFF1.7010909@redhat.com> <20121113213538.GA13472@elliptictech.com> <50A2CC89.8060500@redhat.com> <50A3AD81.2080103@gmail.com> <50A3AFCF.3070008@redhat.com> <50A4CACA.4090702@gmail.com> <50A4D963.2080101@redhat.com> In-Reply-To: <50A4D963.2080101@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.2 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On 11/15/2012 01:00 PM, Eric Blake wrote: > On 11/15/2012 03:58 AM, Stefano Lattarini wrote: >>> As soon as you AC_PREREQ([2.70]), then yes, you can quit tracing >>> AC_CONFIG_MACRO_DIR. >>> >> The below patch should allow our users to employ AC_CONFIG_MACRO_DIRS >> with autoconf 2.69 as well. It still doesn't work with autoconf 2.68 >> and earlier though, due to a bug in autom4te option parsing (fixed by >> autoconf commit v2.68-120-gf4be358). That could be fixed by using an >> external file rather than stdin to pass aclocal the contents of >> '$ac_config_macro_dirs_fallback'; but I rather do so in a separate >> patch, with a dedicated rationale. > > Yes, splitting that into a separate patch makes sense. > > >> * aclocal.in ($ac_config_macro_dirs_fallback): New global variable, >> contains m4 code to issue a fallback definition of AC_CONFIG_MACRO_DIRS >> as an alias for the private macro _AM_CONFIG_MACRO_DIRS. > > Tracing a new private macro - doesn't this imply that autoconf needs to > add another macro to its list of preselections in order to pass the > autoconf testsuite when using the new automake? But don't let that stop > this patch. > Well spotted. But since I'm soon going to remove the private automake macro '_AM_EXTRA_RECURSIVE_TARGETS' as well (the indirection it provides is no longer needed now that aclocal automatically smashes extra whitespace in the arguments of the traced macros), I'd rather wait and make the autoconf update in a single batch. >> +++ b/aclocal.in >> @@ -45,6 +45,16 @@ use File::Path (); >> >> # Some globals. >> >> +# Support AC_CONFIG_MACRO_DIRS also with older autoconf. >> +# FIXME: To be removed in Automake 1.14, once we can assume autoconf >> +# 2.70 or later. >> +# NOTE: This variable deliberately contain no newlines. >> +my $ac_config_macro_dirs_fallback = >> + "m4_ifndef([AC_CONFIG_MACRO_DIRS], [" . >> + "m4_defun([_AM_CONFIG_MACRO_DIRS], [])" . >> + "m4_defun([AC_CONFIG_MACRO_DIRS], [_AM_CONFIG_MACRO_DIRS(\$@)])" . >> + "])"; > > Hmm. Packages that want to work with automake 1.12 and autoconf 2.69, > but still use AC_CONFIG_MACRO_DIRS, may have also added a conditional > definition of AC_CONFIG_MACRO_DIRS in their configure.ac. But it turns > out that you are injecting this snippet after m4sugar definitions (so > m4_ifndef works) but before configure.ac, so your definition will take > precedence. Yep - that works :) > Good point (I must admit I hadn't even thought about this potential issue, sigh). >> + >> # We do not operate in threaded mode. >> $perl_threads = 0; >> >> @@ -716,16 +726,23 @@ sub trace_used_macros () >> my %files = map { $map{$_} => 1 } keys %macro_seen; >> %files = strip_redundant_includes %files; >> >> - my $traces = ($ENV{AUTOM4TE} || '@am_AUTOM4TE@'); >> - $traces .= " --language Autoconf-without-aclocal-m4 "; >> + my $early_m4_code = ""; >> # When AC_CONFIG_MACRO_DIRS is used, avoid possible spurious warnings >> # from autom4te about macros being "m4_require'd but not m4_defun'd"; >> # for more background, see: >> # http://lists.gnu.org/archive/html/autoconf-patches/2012-11/msg00004.html >> # as well as autoconf commit 'v2.69-44-g1ed0548', "warn: allow aclocal >> # to silence m4_require warnings". >> - $traces = "echo 'm4_define([m4_require_silent_probe], [-])' | " . >> - "$traces - "; >> + $early_m4_code .= "m4_define([m4_require_silent_probe], [-])"; >> + # Support AC_CONFIG_MACRO_DIRS also with older autoconf. >> + # FIXME: To be removed in Automake 1.14, once we can assume autoconf >> + # 2.70 or later. >> + $early_m4_code .= $ac_config_macro_dirs_fallback; > > If you are adding a fallback for AC_CONFIG_MACRO_DIRS when running > aclocal, you'll also need to add that fallback when running automake. > (But reading further, it looks like you did.) > >> @@ -738,11 +755,12 @@ sub trace_used_macros () >> 'AC_DEFUN_ONCE', >> 'AU_DEFUN', >> '_AM_AUTOCONF_VERSION', >> - # FIXME: We still need to trace AC_CONFIG_MACRO_DIR >> - # for compatibility with older autoconf. Remove this >> - # when we can assume Autoconf 2.70 or later. >> + 'AC_CONFIG_MACRO_DIR_TRACE', >> + # FIXME: This is an hack for compatibility with older > > s/an hack/a hack/ - use 'a' before a pronounced 'h', 'an' before a > silent 'h'. > As you have already told me several times already. Sorry for forgetting once again. >> + # autoconf. Remove this in Automake 1.14, when we can >> + # assume Autoconf 2.70 or later. >> 'AC_CONFIG_MACRO_DIR', >> - 'AC_CONFIG_MACRO_DIR_TRACE')), >> + '_AM_CONFIG_MACRO_DIRS')), > > Isn't it really: "These next two variables are a hack" > Yes. Isn't that clear? Anyway, to remove possible confusion, I've updated the comment to use your wording. >> --- a/doc/automake.texi >> +++ b/doc/automake.texi >> >> @example >> -AC_CONFIG_MACRO_DIR([m4]) >> +AC_CONFIG_MACRO_DIRS([m4]) >> @end example > > It _might_ be worth mentioning that you must use one or both of automake > 1.13 or autoconf 2.70 to have this work, > Actually, Automake 1.13 is both enough *and* required to have this work (after the next patch, that you have already reviewed); and since this will be the manual for 1.13, there is no need to specify that explicitly. > and that back-compat to automake 1.12 and autoconf 2.69 requires manual > effort in configure.ac. > > Meanwhile, I ought to do the same in the autoconf manual. > > ACK once you fix the comment. > Done: ... 'AC_CONFIG_MACRO_DIR_TRACE', # FIXME: Tracing the next two macros is a hack for # compatibility with older autoconf. Remove this in # Automake 1.14, when we can assume Autoconf 2.70 or # later. 'AC_CONFIG_MACRO_DIR', '_AM_CONFIG_MACRO_DIRS')), ... Thanks, Stefano From unknown Thu Sep 11 09:17:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#12845: [PATCH] aclocal: tracing AC_CONFIG_MACRO_DIRS can work with older autoconf as well Resent-From: Eric Blake Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Thu, 15 Nov 2012 12:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12845 X-GNU-PR-Package: automake X-GNU-PR-Keywords: moreinfo patch To: Stefano Lattarini Cc: Nick Bowler , "automake-patches@gnu.org" , 12845@debbugs.gnu.org, Autoconf Patches List , Adrian Bunk Received: via spool by 12845-submit@debbugs.gnu.org id=B12845.135298407318795 (code B ref 12845); Thu, 15 Nov 2012 12:55:01 +0000 Received: (at 12845) by debbugs.gnu.org; 15 Nov 2012 12:54:33 +0000 Received: from localhost ([127.0.0.1]:44324 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYyxl-0004t6-II for submit@debbugs.gnu.org; Thu, 15 Nov 2012 07:54:33 -0500 Received: from mx1.redhat.com ([209.132.183.28]:3624) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYyxj-0004sy-Bu for 12845@debbugs.gnu.org; Thu, 15 Nov 2012 07:54:33 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qAFCrn7Y024747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Nov 2012 07:53:49 -0500 Received: from [10.3.113.23] (ovpn-113-23.phx2.redhat.com [10.3.113.23]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qAFCrjKB026200; Thu, 15 Nov 2012 07:53:45 -0500 Message-ID: <50A4E5D7.5040404@redhat.com> Date: Thu, 15 Nov 2012 05:53:43 -0700 From: Eric Blake Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 References: <20121112220112.GA1712@bunk.dyndns.info> <20121112221323.GA23877@elliptictech.com> <50A175F9.9090200@redhat.com> <20121112224129.GA24020@elliptictech.com> <20121112231213.GB1712@bunk.dyndns.info> <20121113143045.GA27271@elliptictech.com> <20121113185145.GA29576@bunk.dyndns.info> <20121113194408.GA26711@elliptictech.com> <50A2AAB2.4090200@gmail.com> <50A2AFF1.7010909@redhat.com> <20121113213538.GA13472@elliptictech.com> <50A2CC89.8060500@redhat.com> <50A3AD81.2080103@gmail.com> <50A3AFCF.3070008@redhat.com> <50A4CACA.4090702@gmail.com> <50A4D963.2080101@redhat.com> <50A4E440.2040903@gmail.com> In-Reply-To: <50A4E440.2040903@gmail.com> X-Enigmail-Version: 1.4.5 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig09844143D8A09ADF80E12B84" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Spam-Score: -4.3 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -7.0 (-------) This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig09844143D8A09ADF80E12B84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/15/2012 05:46 AM, Stefano Lattarini wrote: >>> * aclocal.in ($ac_config_macro_dirs_fallback): New global variable, >>> contains m4 code to issue a fallback definition of AC_CONFIG_MACRO_DI= RS >>> as an alias for the private macro _AM_CONFIG_MACRO_DIRS. >> >> Tracing a new private macro - doesn't this imply that autoconf needs t= o >> add another macro to its list of preselections in order to pass the >> autoconf testsuite when using the new automake? But don't let that st= op >> this patch. >> > Well spotted. But since I'm soon going to remove the private automake > macro '_AM_EXTRA_RECURSIVE_TARGETS' as well (the indirection it provide= s > is no longer needed now that aclocal automatically smashes extra > whitespace in the arguments of the traced macros), I'd rather wait and > make the autoconf update in a single batch. Is _AM_EXTRA_RECURSIVE_TARGETS ever traced in any released version of automake? If so, you can't remove it from the pre-selections, even if newer automake no longer traces it. Basically, the preselections must be the union of anything that any released autotool wants to trace. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig09844143D8A09ADF80E12B84 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBCAAGBQJQpOXYAAoJEKeha0olJ0Nqi6MIAJ4HFfz1R4qJxsU5cL4Bjid5 iIz0wOP3J+WqYBUd0C8iR7b0bfG12HjScNnuVyAa6mGNr3D/lhYqT07Rt5SbaI+W zrWlJBogIR11lL2tJyEMnMkvSScoe4QJ0bfFg5fe/iiiMeH1kVmo0jS0BUIAcvv6 CjhsTgaTBYM3u7UCptrACwhBy3xlslXbKAU2zx/6/VG0oYRyYzizd72A4Tdql26z 2gJKlOKbI2bVq3griRyhnWb985LOD+YGmBxxcwU0e3L8Sv1tZVD1tKE8v2s6Yddq tt7cRROHI2VxJhvun1eMUoR/S/3mUcsR8JzeztxnWuezsNUden1uJOyZGnzMZbg= =uxx9 -----END PGP SIGNATURE----- --------------enig09844143D8A09ADF80E12B84-- From unknown Thu Sep 11 09:17:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#12845: [PATCH] aclocal: tracing AC_CONFIG_MACRO_DIRS can work with older autoconf as well Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Thu, 15 Nov 2012 13:10:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12845 X-GNU-PR-Package: automake X-GNU-PR-Keywords: moreinfo patch To: Eric Blake Cc: Nick Bowler , "automake-patches@gnu.org" , 12845@debbugs.gnu.org, Autoconf Patches List , Adrian Bunk Received: via spool by 12845-submit@debbugs.gnu.org id=B12845.135298497120245 (code B ref 12845); Thu, 15 Nov 2012 13:10:01 +0000 Received: (at 12845) by debbugs.gnu.org; 15 Nov 2012 13:09:31 +0000 Received: from localhost ([127.0.0.1]:44430 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYzCB-0005GP-HB for submit@debbugs.gnu.org; Thu, 15 Nov 2012 08:09:30 -0500 Received: from mail-bk0-f44.google.com ([209.85.214.44]:57868) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYzC8-0005GF-1c for 12845@debbugs.gnu.org; Thu, 15 Nov 2012 08:09:25 -0500 Received: by mail-bk0-f44.google.com with SMTP id w11so725429bku.3 for <12845@debbugs.gnu.org>; Thu, 15 Nov 2012 05:08:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=mdIxMwqOBUvBYJW2QkzasOS00hlURd/4Zczmhrs2Xdk=; b=UiziICRSBpQU1plY8rSC1mevTV77gseEgUj2Zm0Z+C+sXtL83fR5FjO/j4deJSn7Or nQRR0PtM0OHS4Jh0aizdLb6oaXzuavtKnD9TvLgX8RxAORHCvMbcY08Zxi/FARJtrXPj lhjmIrt0irI294uTm9iBPFwbFPRT69NMTdj6MDdqqQ89BuUqM47cXdriD1pEzD+8qA1t pCacMCh8Np0h/NVAKGkGWsTCZTKUlm2qSuqBPGvc9GcYY74t1Qu4VLJ4dnl3rvOkKvxd iPyjiifqr3ed4SwJgnOIuZ8DqigntvJZ6DGWcTVyIFvPamT/uqXBaK7YzemsNJpzd/Ae uB0g== Received: by 10.204.128.155 with SMTP id k27mr372094bks.26.1352984922303; Thu, 15 Nov 2012 05:08:42 -0800 (PST) Received: from [192.168.178.21] (host247-100-dynamic.8-87-r.retail.telecomitalia.it. [87.8.100.247]) by mx.google.com with ESMTPS id gy18sm10188437bkc.4.2012.11.15.05.08.39 (version=SSLv3 cipher=OTHER); Thu, 15 Nov 2012 05:08:40 -0800 (PST) Message-ID: <50A4E955.5040703@gmail.com> Date: Thu, 15 Nov 2012 14:08:37 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <20121112220112.GA1712@bunk.dyndns.info> <20121112221323.GA23877@elliptictech.com> <50A175F9.9090200@redhat.com> <20121112224129.GA24020@elliptictech.com> <20121112231213.GB1712@bunk.dyndns.info> <20121113143045.GA27271@elliptictech.com> <20121113185145.GA29576@bunk.dyndns.info> <20121113194408.GA26711@elliptictech.com> <50A2AAB2.4090200@gmail.com> <50A2AFF1.7010909@redhat.com> <20121113213538.GA13472@elliptictech.com> <50A2CC89.8060500@redhat.com> <50A3AD81.2080103@gmail.com> <50A3AFCF.3070008@redhat.com> <50A4CACA.4090702@gmail.com> <50A4D963.2080101@redhat.com> <50A4E440.2040903@gmail.com> <50A4E5D7.5040404@redhat.com> In-Reply-To: <50A4E5D7.5040404@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) On 11/15/2012 01:53 PM, Eric Blake wrote: > On 11/15/2012 05:46 AM, Stefano Lattarini wrote: > >>>> * aclocal.in ($ac_config_macro_dirs_fallback): New global variable, >>>> contains m4 code to issue a fallback definition of AC_CONFIG_MACRO_DIRS >>>> as an alias for the private macro _AM_CONFIG_MACRO_DIRS. >>> >>> Tracing a new private macro - doesn't this imply that autoconf needs to >>> add another macro to its list of preselections in order to pass the >>> autoconf testsuite when using the new automake? But don't let that stop >>> this patch. >>> >> Well spotted. But since I'm soon going to remove the private automake >> macro '_AM_EXTRA_RECURSIVE_TARGETS' as well (the indirection it provides >> is no longer needed now that aclocal automatically smashes extra >> whitespace in the arguments of the traced macros), I'd rather wait and >> make the autoconf update in a single batch. > > Is _AM_EXTRA_RECURSIVE_TARGETS ever traced in any released version of > automake? > No, that's why I wanted to remove it. > If so, you can't remove it from the pre-selections, even if > newer automake no longer traces it. Basically, the preselections must > be the union of anything that any released autotool wants to trace. > I was aware of this. But thanks for spelling it out explicitly anyway. Thanks, Stefano From unknown Thu Sep 11 09:17:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#12845: [PATCH] aclocal: tracing AC_CONFIG_MACRO_DIRS can work with older autoconf as well Resent-From: Eric Blake Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Thu, 15 Nov 2012 13:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12845 X-GNU-PR-Package: automake X-GNU-PR-Keywords: moreinfo patch To: Stefano Lattarini Cc: Nick Bowler , "automake-patches@gnu.org" , 12845@debbugs.gnu.org, Autoconf Patches List , Adrian Bunk Received: via spool by 12845-submit@debbugs.gnu.org id=B12845.135298526020674 (code B ref 12845); Thu, 15 Nov 2012 13:15:02 +0000 Received: (at 12845) by debbugs.gnu.org; 15 Nov 2012 13:14:20 +0000 Received: from localhost ([127.0.0.1]:44435 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYzGo-0005NG-TB for submit@debbugs.gnu.org; Thu, 15 Nov 2012 08:14:19 -0500 Received: from mx1.redhat.com ([209.132.183.28]:26393) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYzGj-0005N3-SJ for 12845@debbugs.gnu.org; Thu, 15 Nov 2012 08:14:12 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qAFDDRao010614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Nov 2012 08:13:27 -0500 Received: from [10.3.113.23] (ovpn-113-23.phx2.redhat.com [10.3.113.23]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qAFDDQAM030967; Thu, 15 Nov 2012 08:13:26 -0500 Message-ID: <50A4EA75.8070500@redhat.com> Date: Thu, 15 Nov 2012 06:13:25 -0700 From: Eric Blake Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 References: <20121112220112.GA1712@bunk.dyndns.info> <20121112221323.GA23877@elliptictech.com> <50A175F9.9090200@redhat.com> <20121112224129.GA24020@elliptictech.com> <20121112231213.GB1712@bunk.dyndns.info> <20121113143045.GA27271@elliptictech.com> <20121113185145.GA29576@bunk.dyndns.info> <20121113194408.GA26711@elliptictech.com> <50A2AAB2.4090200@gmail.com> <50A2AFF1.7010909@redhat.com> <20121113213538.GA13472@elliptictech.com> <50A2CC89.8060500@redhat.com> <50A3AD81.2080103@gmail.com> <50A3AFCF.3070008@redhat.com> <50A4CACA.4090702@gmail.com> <50A4D963.2080101@redhat.com> <50A4E440.2040903@gmail.com> <50A4E5D7.5040404@redhat.com> <50A4E955.5040703@gmail.com> In-Reply-To: <50A4E955.5040703@gmail.com> X-Enigmail-Version: 1.4.5 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig609C1543ECEFCB8E7FF8D54A" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Spam-Score: -4.3 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -7.0 (-------) This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig609C1543ECEFCB8E7FF8D54A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/15/2012 06:08 AM, Stefano Lattarini wrote: >> Is _AM_EXTRA_RECURSIVE_TARGETS ever traced in any released version of >> automake? >> > No, that's why I wanted to remove it. >=20 >> If so, you can't remove it from the pre-selections, even if >> newer automake no longer traces it. Basically, the preselections must= >> be the union of anything that any released autotool wants to trace. >> > I was aware of this. But thanks for spelling it out explicitly anyway.= Glad to hear we're on the same page, then. And saves me the effort of researching something in a codebase you are more familiar with :O) --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig609C1543ECEFCB8E7FF8D54A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBCAAGBQJQpOp1AAoJEKeha0olJ0NqPFIH/A0JyfK4srdpoBzVMB/nTgKQ EvB702FgATG3Paz0EGgaZo/lkbNbf0yvb0AZVW+J/JHx7kRSaCmwyZuw83WyU2Sh ldxJ3IzfGVf1dsgYZDzD+hBuQqoF3MZDeAO/f0xYde0CT0pgx9MjpF7KMMAb8Juu YhJbF5QYZZ6Bzn1iHjl8bIdjqpqCJRQgbvDm0qn6WOLWaOD5jktezTnvagjExwhd gm8xirubNDXC/V+F/okhoV08GTY3ybrpsZECJAqpfDe+ZFm31lwLrsEDKm+AHYO2 2OWCDVqnYtbc7cVFXVZ7aJXKpIPDmXkx6hLkEuGvXmpzo2+b2emzehTh6r7ptr8= =xBle -----END PGP SIGNATURE----- --------------enig609C1543ECEFCB8E7FF8D54A-- From unknown Thu Sep 11 09:17:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#12845: [PATCH] aclocal: tracing AC_CONFIG_MACRO_DIRS can work with older autoconf as well Resent-From: Stefano Lattarini Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-automake@gnu.org Resent-Date: Thu, 15 Nov 2012 13:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12845 X-GNU-PR-Package: automake X-GNU-PR-Keywords: moreinfo patch To: Eric Blake Cc: Nick Bowler , "automake-patches@gnu.org" , 12845@debbugs.gnu.org, Autoconf Patches List , Adrian Bunk Received: via spool by 12845-submit@debbugs.gnu.org id=B12845.135298571821452 (code B ref 12845); Thu, 15 Nov 2012 13:22:01 +0000 Received: (at 12845) by debbugs.gnu.org; 15 Nov 2012 13:21:58 +0000 Received: from localhost ([127.0.0.1]:44508 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYzOH-0005Zv-Ja for submit@debbugs.gnu.org; Thu, 15 Nov 2012 08:21:57 -0500 Received: from mail-la0-f44.google.com ([209.85.215.44]:57755) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TYzOE-0005Zn-Ll for 12845@debbugs.gnu.org; Thu, 15 Nov 2012 08:21:55 -0500 Received: by mail-la0-f44.google.com with SMTP id d3so1307166lah.3 for <12845@debbugs.gnu.org>; Thu, 15 Nov 2012 05:21:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Qsa3vh1bfpr95qK3U0CHZkXO3klfBvM6AVkGIycHl7o=; b=Q9ILNLG1kAMqWMbDgjxnkxvhFRBAPK+579OQRC2yj84xBvtBx2GAsRHAM0yyW2XF/R hL5r17eQGABeiiJgY5KIuUV6x97LpwVvm5glEIZJzIdev3X62w9x9VatUulsLzZkIn19 +d+DERw1e9e0GGKKcndERSmr7XZTM/95yQTnsCvr9/82QKkPiLXTRUTXPLtP7vvT1QQS p8A6HfM0cWhKoBYrACGhwi4W0Bw1BPmgjOGm/sw01Xs3TVc3ekFu2DX+4MdePk2MGv6z Rg9aeDntiUmMEhHbzkPzkmausSxus+joUJXFuFyYW75/Gy4JlugZP0PI110ZXJaeR6GE tZrA== Received: by 10.112.17.234 with SMTP id r10mr588854lbd.72.1352985672369; Thu, 15 Nov 2012 05:21:12 -0800 (PST) Received: from [192.168.178.21] (host247-100-dynamic.8-87-r.retail.telecomitalia.it. [87.8.100.247]) by mx.google.com with ESMTPS id p9sm6256131lbc.3.2012.11.15.05.21.10 (version=SSLv3 cipher=OTHER); Thu, 15 Nov 2012 05:21:11 -0800 (PST) Message-ID: <50A4EC43.6010001@gmail.com> Date: Thu, 15 Nov 2012 14:21:07 +0100 From: Stefano Lattarini MIME-Version: 1.0 References: <20121112220112.GA1712@bunk.dyndns.info> <20121112221323.GA23877@elliptictech.com> <50A175F9.9090200@redhat.com> <20121112224129.GA24020@elliptictech.com> <20121112231213.GB1712@bunk.dyndns.info> <20121113143045.GA27271@elliptictech.com> <20121113185145.GA29576@bunk.dyndns.info> <20121113194408.GA26711@elliptictech.com> <50A2AAB2.4090200@gmail.com> <50A2AFF1.7010909@redhat.com> <20121113213538.GA13472@elliptictech.com> <50A2CC89.8060500@redhat.com> <50A3AD81.2080103@gmail.com> <50A3AFCF.3070008@redhat.com> <50A4CACA.4090702@gmail.com> <50A4D963.2080101@redhat.com> <50A4E440.2040903@gmail.com> <50A4E5D7.5040404@redhat.com> <50A4E955.5040703@gmail.com> <50A4EA75.8070500@redhat.com> In-Reply-To: <50A4EA75.8070500@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) On 11/15/2012 02:13 PM, Eric Blake wrote: > On 11/15/2012 06:08 AM, Stefano Lattarini wrote: >>> Is _AM_EXTRA_RECURSIVE_TARGETS ever traced in any released version of >>> automake? >>> >> No, that's why I wanted to remove it. >> More importantly, we'll have to start pre-selecting the 'AM_EXTRA_RECURSIVE_TARGETS' macro instead (note missing underscore in the name). I will submit proper patch once the flurry of changes in automake settles down. Regards, Stefano From unknown Thu Sep 11 09:17:53 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.428 (Entity 5.428) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Stefano Lattarini Subject: bug#12845: closed (Closing this report) Message-ID: References: <50B367DD.6090802@gmail.com> <509D44FF.5010002@gmail.com> X-Gnu-PR-Message: they-closed 12845 X-Gnu-PR-Package: automake X-Gnu-PR-Keywords: moreinfo patch Reply-To: 12845@debbugs.gnu.org Date: Mon, 26 Nov 2012 13:03:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1353934982-8091-1" This is a multi-part message in MIME format... ------------=_1353934982-8091-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #12845: aclocal: stop handling AC_CONFIG_MACRO_DIR; handle just AC_CONFIG_M= ACRO_DIRS (was: Re: [PATCH 1/2] AC_CONFIG_MACRO_DIRS: new macro, mostly for= aclocal which was filed against the automake package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 12845@debbugs.gnu.org. --=20 12845: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D12845 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1353934982-8091-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 12845-done) by debbugs.gnu.org; 26 Nov 2012 13:02:06 +0000 Received: from localhost ([127.0.0.1]:39397 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TcyK4-00025L-Ix for submit@debbugs.gnu.org; Mon, 26 Nov 2012 08:02:05 -0500 Received: from mail-la0-f44.google.com ([209.85.215.44]:47309) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TcyK1-00024v-Kj for 12845-done@debbugs.gnu.org; Mon, 26 Nov 2012 08:02:02 -0500 Received: by mail-la0-f44.google.com with SMTP id d3so9358854lah.3 for <12845-done@debbugs.gnu.org>; Mon, 26 Nov 2012 05:00:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:mime-version:to:subject:content-type :content-transfer-encoding; bh=ocZAp6Ur3njpdnd3yEIFXLaMwk0hzTBuoFeeAPbIP/U=; b=B5f/qWMKgtTAHA2HhlyNqU90tGmCeojQHxfXh7wRuErpcQJDKh8+39fFnfbN8tQOzE nabO5XrmjKIKZRwQOCJbcl21On7dWeZ0wh0yTPBkSUJO7Fc0yoombZLqTbwwk1M5AyUu rzvPAY2x8+lIAuSmjLQKCmO637q9B0kgayqFcBKlnVzTC6IIXSyYM2AAC1xxyT2kvHO9 GV34hhSiUsMFp7ju/l3SI+SWHI1O3MfCjC2E0MTcwjW7kRRil7/HOLo8FOekj7F9KNDU S+/curEDcM6RVYS//HnGJlaCo+Q1MBfhZQqJWIrqEJkwBwuYysZy5ZodrBS0Rd5UTF2C 0ttA== Received: by 10.112.83.42 with SMTP id n10mr1218267lby.116.1353934817556; Mon, 26 Nov 2012 05:00:17 -0800 (PST) Received: from [192.168.178.21] (host54-50-dynamic.58-82-r.retail.telecomitalia.it. [82.58.50.54]) by mx.google.com with ESMTPS id m3sm5620448lbb.13.2012.11.26.05.00.15 (version=SSLv3 cipher=OTHER); Mon, 26 Nov 2012 05:00:16 -0800 (PST) Message-ID: <50B367DD.6090802@gmail.com> Date: Mon, 26 Nov 2012 14:00:13 +0100 From: Stefano Lattarini MIME-Version: 1.0 To: 12845-done@debbugs.gnu.org Subject: Closing this report Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 12845-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) All the issues explored here should now be satisfactorily solved in the master branch of the Automake repository. I'm thus closing this report. Regards, Stefano ------------=_1353934982-8091-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 9 Nov 2012 18:02:16 +0000 Received: from localhost ([127.0.0.1]:58280 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TWsuF-00008y-U5 for submit@debbugs.gnu.org; Fri, 09 Nov 2012 13:02:16 -0500 Received: from eggs.gnu.org ([208.118.235.92]:38699) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TWsuD-00008o-2u for submit@debbugs.gnu.org; Fri, 09 Nov 2012 13:02:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TWsu0-00067V-9f for submit@debbugs.gnu.org; Fri, 09 Nov 2012 13:02:04 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:59609) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TWsu0-00067Q-73 for submit@debbugs.gnu.org; Fri, 09 Nov 2012 13:02:00 -0500 Received: from eggs.gnu.org ([208.118.235.92]:42872) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TWstw-0004a4-7c for bug-automake@gnu.org; Fri, 09 Nov 2012 13:02:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TWstr-000648-Cl for bug-automake@gnu.org; Fri, 09 Nov 2012 13:01:56 -0500 Received: from mail-bk0-f41.google.com ([209.85.214.41]:51049) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TWstn-00063N-V9; Fri, 09 Nov 2012 13:01:48 -0500 Received: by mail-bk0-f41.google.com with SMTP id jm1so1921877bkc.0 for ; Fri, 09 Nov 2012 10:01:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Zkkph1bDARWdwZKkV9rPOzfHm9UfXiCm5bz5yUb2I60=; b=MrjJntp0bK1zSnL638du5q1fZCPnc8YRqxwDeORp8o5858tGvrDGcSG1V5kzBgbE6C DhhJ8lGa+dTrNDhrEdqYi28P8FOWqsMKoQG0t0SiUAe3/gJYeYji5a4pIWgC9dapk/Cy NXPIDcCW/XHJKw4EfNoyboXnYGsCpy4Yy0PTmPX8JLC68NWIcCfQGkWmqVzK3A5AZfuY Q7lqGNbb7nT2y38clNiMITxltxxqPe7PGZXiJHpBpV9D3jqCBUReAQSORiPIR4xE+R4l k2m7vX4+iMrn9sV5M+tqZU82c+uhONPWNhyyLJoaKoT96Zn/A4segFlbCtQ1JYnFp2TO 6VvA== Received: by 10.204.146.83 with SMTP id g19mr4121374bkv.33.1352484106695; Fri, 09 Nov 2012 10:01:46 -0800 (PST) Received: from [192.168.178.21] (host247-100-dynamic.8-87-r.retail.telecomitalia.it. [87.8.100.247]) by mx.google.com with ESMTPS id z22sm19740976bkw.2.2012.11.09.10.01.43 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 10:01:45 -0800 (PST) Message-ID: <509D44FF.5010002@gmail.com> Date: Fri, 09 Nov 2012 19:01:35 +0100 From: Stefano Lattarini MIME-Version: 1.0 To: Nick Bowler Subject: aclocal: stop handling AC_CONFIG_MACRO_DIR; handle just AC_CONFIG_MACRO_DIRS (was: Re: [PATCH 1/2] AC_CONFIG_MACRO_DIRS: new macro, mostly for aclocal References: <507E5D75.5040306@gmail.com> <529492dab6dec00f88c5e54adf8f257c5470fd74.1350468731.git.stefano.lattarini@gmail.com> <5094311D.2040801@redhat.com> <509465EB.1000701@gmail.com> <20121109160001.GF8324@bunk.dyndns.info> <20121109163334.GA3105@elliptictech.com> In-Reply-To: <20121109163334.GA3105@elliptictech.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -3.4 (---) X-Debbugs-Envelope-To: submit Cc: bug-automake@gnu.org, autoconf-patches@gnu.org, Eric Blake , Adrian Bunk X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.4 (---) [+cc bug-automake] On 11/09/2012 05:33 PM, Nick Bowler wrote: > On 2012-11-09 18:00 +0200, Adrian Bunk wrote: >> On Sat, Nov 03, 2012 at 01:31:39AM +0100, Stefano Lattarini wrote: >>> On 11/02/2012 09:46 PM, Eric Blake wrote: >>>> On 10/17/2012 04:15 AM, Stefano Lattarini wrote: > [...] >>>> Hmm, I'm wondering if we should do something fancier, and have both >>>> AC_CONFIG_MACRO_DIR and AC_CONFIG_MACRO_DIRS collaborate so that the >>>> FIRST call to either macro causes AC_CONFIG_MACRO_DIR to be traced. >>>> >>> Considering that I'd like to see AC_CONFIG_MACRO_DIR deprecated in >>> Autoconf 2.71 and removed in Autoconf 2.72, I believe that would be >>> a bit of an overkill. >>> ... >> >> It is completely crazy to imagine removing a macro in Autoconf 2.72 >> that is as of today used in half of all configure.ac files. [1] >> >> Did you ever consider the consequences e.g. for Debian, where more than >> thousand packages are re-running autoconf at package build time? >> "We have to fix 1000 packages before we can upgrade to autoconf 2.72 >> in Debian" sounds like a pretty horrible situation for both Debian >> and autoconf. >> >> Marking it as deprecated in Autoconf 2.71 with a possible removal >> 10 years later sounds like a more realistic schedule. > > To be honest I don't see the point in removing the macro ever, since > it doesn't actually do anything. > Good point. Unfortunately, the current development version of aclocal has started to recognize and handle AC_CONFIG_MACRO_DIR. But we can easily change that once 'AC_CONFIG_MACRO_DIRS' is implemented, by having aclocal recognize only this later macro; and we can do so without any backward-incompatibility, since the code handling AC_CONFIG_MACRO_DIR has not made it into any released aclocal version. I'm CC:ing this message to the bug-automake list so that I won't forgot about the issue ... > Removing it from the documentation > (except perhaps for historical reference) and marking it deprecated > would be prudent, however. > > By the same token, to avoid any regressions, let's not change the > behaviour of AC_CONFIG_MACRO_DIR by suddenly making it do more than > nothing. > I agree; and as I said, I plan to remove aclocal's new-found ability to handle AC_CONFIG_MACRO_DIR before releasing Automake 1.13. Thanks, Stefano ------------=_1353934982-8091-1--