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

[Stefano Lattarini]

On 10/17/2012 10:05 PM, Nick Bowler wrote:
> 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.
>
Of course, they were written before these autoconf patches :-)

Anyway, I agree some early testing by real users would be very useful,
so here is a first cut at the Automake part of the AC_CONFIG_MACRO_DIRS
support (see attached patches).

>>> 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.
>
IMHO, that is no more true after automake commit v1.12.1-165-gcd1a9cc:
<http://git.savannah.gnu.org/cgit/automake.git/commit/?h=ng/master&id=v1.12.1-165-gcd1a9cc>
But of course, the new semantics of AC_CONFIG_MACRO_DIR will be more
powerful (allowing declaration of multiple local m4 directories), so
that's the way to go in the future.

> 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,

Thanks,
  Stefano

0001-aclocal-multiple-local-m4-macro-dirs-with-AC_CONFIG_.patch
Description: Text Data

0002-aclocal-diagnose-non-existing-directories-in-AC_CONF.patch
Description: Text Data