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
