Re: [PATCH] AC_CONFIG_MACRO_DIRS: improve tracing and add sanity checks

[Nick Bowler]

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,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)