GNU bug report logs -
#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
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12845 in the body.
You can then email your comments to 12845 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-automake <at> gnu.org:
bug#12845; Package
automake.
(Fri, 09 Nov 2012 18:03:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stefano Lattarini <stefano.lattarini <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-automake <at> gnu.org.
(Fri, 09 Nov 2012 18:03:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[+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
Information forwarded
to
bug-automake <at> gnu.org:
bug#12845; Package
automake.
(Sat, 10 Nov 2012 12:33:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 12845 <at> debbugs.gnu.org (full text, mbox):
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
Added tag(s) wontfix.
Request was from
Stefano Lattarini <stefano.lattarini <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Sat, 10 Nov 2012 12:33:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
12845 <at> debbugs.gnu.org and Stefano Lattarini <stefano.lattarini <at> gmail.com>
Request was from
Stefano Lattarini <stefano.lattarini <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Sat, 10 Nov 2012 12:33:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-automake <at> gnu.org:
bug#12845; Package
automake.
(Tue, 13 Nov 2012 20:18:02 GMT)
Full text and
rfc822 format available.
Message #15 received at 12845 <at> debbugs.gnu.org (full text, mbox):
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
Did not alter fixed versions and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 13 Nov 2012 20:18:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-automake <at> gnu.org:
bug#12845; Package
automake.
(Tue, 13 Nov 2012 20:40:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 12845 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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.
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.
>
> 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.
>
> 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.
>
> 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.
--
Eric Blake eblake <at> redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-automake <at> gnu.org:
bug#12845; Package
automake.
(Tue, 13 Nov 2012 21:37:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 12845 <at> debbugs.gnu.org (full text, mbox):
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/)
Information forwarded
to
bug-automake <at> gnu.org:
bug#12845; Package
automake.
(Tue, 13 Nov 2012 22:42:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 12845 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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. I think all
> of us agree that this is the most common case.
Yep, and it works.
>
> (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.
>
> (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.
>
> (3) Packages that use more than one AC_CONFIG_MACRO_DIR. You argue
> that this was broken to begin with.
Correct.
>
> (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.
>
> 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.
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.
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.
>
> * 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, 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.
>
> 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.
>
> [...]
>> 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.
--
Eric Blake eblake <at> redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-automake <at> gnu.org:
bug#12845; Package
automake.
(Tue, 13 Nov 2012 22:58:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 12845 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-automake <at> gnu.org:
bug#12845; Package
automake.
(Wed, 14 Nov 2012 14:42:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 12845 <at> debbugs.gnu.org (full text, mbox):
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:
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9037>
> 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
Information forwarded
to
bug-automake <at> gnu.org:
bug#12845; Package
automake.
(Wed, 14 Nov 2012 14:52:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 12845 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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.
--
Eric Blake eblake <at> redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Removed tag(s) wontfix.
Request was from
Stefano Lattarini <stefano.lattarini <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Wed, 14 Nov 2012 14:54:02 GMT)
Full text and
rfc822 format available.
Added tag(s) moreinfo.
Request was from
Stefano Lattarini <stefano.lattarini <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Wed, 14 Nov 2012 14:54:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-automake <at> gnu.org:
bug#12845; Package
automake.
(Wed, 14 Nov 2012 22:21:01 GMT)
Full text and
rfc822 format available.
Message #42 received at 12845 <at> debbugs.gnu.org (full text, mbox):
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/)
Information forwarded
to
bug-automake <at> gnu.org:
bug#12845; Package
automake.
(Thu, 15 Nov 2012 11:00:02 GMT)
Full text and
rfc822 format available.
Message #45 received at 12845 <at> debbugs.gnu.org (full text, mbox):
[+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: <a966b8bde5fe8bb4927ade875d80e057b4d3fa2f.1352977009.git.stefano.lattarini <at> gmail.com>
From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
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:
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12845>
* 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 <stefano.lattarini <at> gmail.com>
---
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 - <<END
- AC_INIT([x], [0])
- AC_CONFIG_MACRO_DIRS([.])
-END
-} || skip_all_ "autoconf doesn't define the AC_CONFIG_MACRO_DIRS macro"
-
plan_ 14
ocwd=$(pwd) || fatal_ "getting current working directory"
diff --git a/t/subpkg-macrodir.sh b/t/subpkg-macrodir.sh
index 275af0d..a16f42b 100755
--- a/t/subpkg-macrodir.sh
+++ b/t/subpkg-macrodir.sh
@@ -19,12 +19,6 @@
. test-init.sh
-{ $AUTOCONF -o /dev/null - <<END
- AC_INIT([x], [0])
- AC_CONFIG_MACRO_DIRS([.])
-END
-} || skip_ "autoconf doesn't define the AC_CONFIG_MACRO_DIRS macro"
-
cat > configure.ac <<'END'
AC_INIT([super], [1.0])
AM_INIT_AUTOMAKE
--
1.8.0
Information forwarded
to
bug-automake <at> gnu.org:
bug#12845; Package
automake.
(Thu, 15 Nov 2012 11:54:02 GMT)
Full text and
rfc822 format available.
Message #48 received at 12845 <at> debbugs.gnu.org (full text, mbox):
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: <a5cddc48e23a650c75f270dcb2e63d57ea3aa07b.1352980173.git.stefano.lattarini <at> gmail.com>
From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
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 <stefano.lattarini <at> gmail.com>
---
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
Information forwarded
to
bug-automake <at> gnu.org:
bug#12845; Package
automake.
(Thu, 15 Nov 2012 12:29:01 GMT)
Full text and
rfc822 format available.
Message #51 received at 12845 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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/
> +# '$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($@)])])
--
Eric Blake eblake <at> redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-automake <at> gnu.org:
bug#12845; Package
automake.
(Thu, 15 Nov 2012 12:29:02 GMT)
Full text and
rfc822 format available.
Message #54 received at 12845 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 ();
>
> # 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 :)
> +
> # 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'.
> + # 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"
> +++ 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
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.
--
Eric Blake eblake <at> redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-automake <at> gnu.org:
bug#12845; Package
automake.
(Thu, 15 Nov 2012 12:37:02 GMT)
Full text and
rfc822 format available.
Message #57 received at 12845 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-automake <at> gnu.org:
bug#12845; Package
automake.
(Thu, 15 Nov 2012 12:48:01 GMT)
Full text and
rfc822 format available.
Message #60 received at 12845 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-automake <at> gnu.org:
bug#12845; Package
automake.
(Thu, 15 Nov 2012 12:55:01 GMT)
Full text and
rfc822 format available.
Message #63 received at 12845 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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? 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.
--
Eric Blake eblake <at> redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-automake <at> gnu.org:
bug#12845; Package
automake.
(Thu, 15 Nov 2012 13:10:01 GMT)
Full text and
rfc822 format available.
Message #66 received at 12845 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-automake <at> gnu.org:
bug#12845; Package
automake.
(Thu, 15 Nov 2012 13:15:02 GMT)
Full text and
rfc822 format available.
Message #69 received at 12845 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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.
>
>> 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)
--
Eric Blake eblake <at> redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-automake <at> gnu.org:
bug#12845; Package
automake.
(Thu, 15 Nov 2012 13:22:01 GMT)
Full text and
rfc822 format available.
Message #72 received at 12845 <at> debbugs.gnu.org (full text, mbox):
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
Reply sent
to
Stefano Lattarini <stefano.lattarini <at> gmail.com>:
You have taken responsibility.
(Mon, 26 Nov 2012 13:03:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Stefano Lattarini <stefano.lattarini <at> gmail.com>:
bug acknowledged by developer.
(Mon, 26 Nov 2012 13:03:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 12845-done <at> debbugs.gnu.org (full text, mbox):
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
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 25 Dec 2012 12:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 12 years and 263 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.