Re: [PATCH 1/2] AC_CONFIG_MACRO_DIRS: new macro, mostly for aclocal

[Nick Bowler]

On 2012-10-17 09:25 +0200, Stefano Lattarini wrote:
> On 10/16/2012 10:46 PM, Nick Bowler wrote:
> > I think it's important to have, for testing, a version of aclocal that
> > actually makes use of this feature.
> >
> The reason I wrote this patch is because I want to make use of this
> feature in aclocal 1.13.  See also:
> <http://lists.gnu.org/archive/html/automake-patches/2012-07/msg00030.html>

Right, I didn't mean to suggest that you weren't planning to use it:
what I'd like to see is

 * a patch to autoconf (we have this: currently under discussion)
 * a patch to aclocal
 * a patch to libtoolize

so that people (like me) can apply all these patches, try to convert
their projects to use AC_CONFIG_MACRO_DIRS, and actually see how things
behave first hand.  The linked aclocal patches don't seem like they'd
work with *this* autoconf patch under discussion.

> > That way, it's actually possible to
> > validate that this feature works in a useful manner.  Bonus points for
> > demonstrating that we can kill off ACLOCAL_AMFLAGS entirely (this means
> > patching at least libtool as well as automake and autoconf).  While it's
> > not my call, a testable implementation should be a prerequisite for
> > merging another macro like this into Autoconf.
>
> Well, I agree that is be a prerequisite for adding this new macro into a
> *released* Autoconf, but we can be more relaxed for what concerns the Git
> repository; if this turns out to be a bad idea, we can revert the relevant
> changes before cutting the 2.70 release out of the repository, no?

Well, it seems weird to me commit something to master with the caveat
"we must revert this feature before the next release if it remains
untestable by that time".  But sure, if the Autoconf maintainer(s)
want to do it this way then that's totally their prerogative.

I just want to avoid a repeat of AC_CONFIG_MACRO_DIR where we carry
around a worthless macro forever because it doesn't behave in any useful
manner.  As I mentioned a little while ago on this list[1], I actually
think that, right now, AC_CONFIG_MACRO_DIR has negative value: it has
a maintenence cost to put it in your configure.ac (mainly due to
duplication of information in Makefile.am, gratuitously enforced by
libtoolize) for exactly zero benefit.

PS, as I might not have been clear: I think we absolutely can and should
make this feature work!  I will be happy to delete many occurrences of
ACLOCAL_AMFLAGS the day that happens.

[1] http://permalink.gmane.org/gmane.comp.sysutils.automake.patches/8848

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)