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

Full log

View this message in rfc822 format

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Nick Bowler <nbowler <at> elliptictech.com>
Cc: autoconf-patches <at> gnu.org, Eric Blake <eblake <at> redhat.com>, 12845 <at> debbugs.gnu.org, Adrian Bunk <bunk <at> stusta.de>
Subject: bug#12845: [PATCH] AC_CONFIG_MACRO_DIRS: improve tracing and add sanity checks
Date: Tue, 13 Nov 2012 21:16:50 +0100

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.