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/)