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
