bug#13514: unintentional regression with AC_CONFIG_MACRO_DIR in 1.13.1

[Stefano Lattarini]

Hi Eric, thanks for the report.

On 01/21/2013 02:31 PM, Eric Blake wrote:
> See https://bugzilla.redhat.com/show_bug.cgi?id=901333 for details; but
> the short summary is:
> 
> The xorg-x11-drv-wacom uses AC_CONFIG_MACRO_DIR([m4]) to tell libtool
> where to dump m4 macros, but has no m4 macros of its own.  Therefore, it
> does not ship an m4 directory in its git project.  When libtoolize is
> run, the directory is populated, and after that point, aclocal will
> work; but prior to the first libtool run (and considering that
> autoreconf runs aclocal prior to libtool),
>
Is this order truly correct?  All the tests in the Automake testsuite that
runs libtoolize run it *before* aclocal...

> the directory doesn't exist,
> so the new check in newer automake that fails if AC_CONFIG_MACRO_DIR
> doesn't exist is preventing bootstrap of the package.
> 
> It sounds like our sanity check of whether the macro dir exists is too
> strict,
>
Actually, aclocal does correctly forgo that check when invoked with the
'--install' option, to accommodate those projects that have no m4 macros
of their own, only only use AC_CONFIG_MACRO_DIR to declare the directory
where third-party macros are to be imported in (which is a fully
legitimate usage).  I'm not sure I want this behaviour to be made the
default one though; could we try to fix the problem in autoreconf
instead, if that's feasible?  But then again, see below.

> and that there are legitimate reasons why even the primary
> directory won't exist on the first aclocal run.
> 
Well, you might be right that, even we can fix autoreconf to avoid
the issue on hand, there might be other unforeseen scenarios where
it is legitimate for the primary macro directory not to exist on the
first aclocal invocation.  Maybe the current error should be demoted
to a warning, to allow us to be more forward-compatible with such
possible future scenarios?

Regards,
  Stefano