Thanks for the report, iirc, this is really problem in automake package -- as
calling the 'autoreconf -vfi' should create missing m4 directory for you.  I'll
try to find what exactly causes this issue.

In the meantime, could you use the 'aclocal --install' before calling
autoreconf?  It should work-around this issue for xorg-x11-drv-wacom.

Pavel

(In reply to comment #0)
> Description of problem:
> autoreconf -ivf calls aclocal --force, which checks the AC_CONFIG_MACRO_DIR.
> As of automake 1.13.1 this now fails if the directory is missing.
> 
> Package triggering this is xorg-x11-drv-wacom. The m4 directory is not
> present (it's empty, so not in git/tarball) and created by libtoolize.
> Unfortunately libtoolize is run _after_ aclocal. 
> 
> This appears to be the same issue as described here
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565663

Well, in your case this results (I hope) more like a feature request.  See
the following clarification.

The purpose of AC_CONFIG_MACRO_DIR (which is obsoleted by AC_CONFIG_MACRO_DIRS
in new autotools) has purpose of telling to 'aclocal' where to look for
_user defined_  .m4 files.

Yes, you need m4 directory, because the libtool is involved also.  But for that
purposes, there is second run of aclocal after 'libtoolize' run.  This aclocal
run will look in 'm4' directory because libtoolize created it.  No need to
specify AC_CONFIG_MACRO_DIRS in your case.

Previous automake version probably simply created 'm4' directory.  But it was
bug imo (if it was done silently) — user wants to know, that user defined
macros are missing in distribution, when they are _really_ missing.

It would be probably nice to have some special warning in aclocal saying, what
are the AC_CONFIG_MACRO_DIRS purposes in case, that the specified directory is
missing.  And it imo does not make sense to introduce special warnings for
Fedora, only in case this warning would be upstream accepted.  It would make
sense if there was too many packages having this problem (which I don't
expect).

~~> I'll let this bug opened, it would be nice to propose better solution that
    is proposed in mentioned thread:

    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565663#50

Thanks,
Pavel

So the funny thing though is that if I do remove the call, libtool give me a warning. I know I can ignore this one, but this seems like two tools working against each other.

libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.

Reading http://www.flameeyes.eu/autotools-mythbuster/autoconf/macros.html it suggests that ACLOCAL_AMFLAGS will be ignored in the future too, so libtool's suggestion is even more confusing.

As for AC_CONFIG_MACRO_DIRS, that doesn't appear to work on F18 yet, so we can't move this upstream yet, we want to build against all versions RHEL6 and newer.

Now, don't get me wrong, I don't have a problem removing the call since we obviously don't ship our own macros. Just tell me whether that's the right thing to do (and to ignore the libtoolize warnings). However, this bug is largely here because a package that used to build now doesn't any more, so it's not wacom specific per se.

(In reply to comment #3)
> So the funny thing though is that if I do remove the call, libtool give me a
> warning. I know I can ignore this one, but this seems like two tools working
> against each other.
>
> libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
> libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
> libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.

These libtool's suggestions are bad as both macros should be legacy now.  For
now, I'd prefer to ignore this.

> Reading http://www.flameeyes.eu/autotools-mythbuster/autoconf/macros.html it
> suggests that ACLOCAL_AMFLAGS will be ignored in the future too, so
> libtool's suggestion is even more confusing.

For me, this needs to be fixed.  To don't confuse users.  Libtool does not
follow automake's future steps imo.  But I'll try to consult it with upstream.

> As for AC_CONFIG_MACRO_DIRS, that doesn't appear to work on F18 yet, so we
> can't move this upstream yet, we want to build against all versions RHEL6
> and newer.

Ok, this seems to be real problem.  When you need this macro, you are forced to
use AC_CONFIG_MACRO_DIR (even if this is not your case).

> Now, don't get me wrong, I don't have a problem removing the call since we
> obviously don't ship our own macros. Just tell me whether that's the right
> thing to do (and to ignore the libtoolize warnings). However, this bug is
> largely here because a package that used to build now doesn't any more, so
> it's not wacom specific per se.

I would go this way.  The second maybe more error prone choice could be to add
'm4/README' file in distribution directory - this shouldn't stop working in
future & you pay just small amount of additional work.

CCing people I know that are involved in autotools for discussion.  This
*needs* to be stabilized .. do you think I shoul'd force automake to create
'm4' directory by default (Fedora & upstream)?  Or what are your suggestions?

Pavel

(In reply to comment #3)
> So the funny thing though is that if I do remove the call, libtool give me a
> warning. I know I can ignore this one, but this seems like two tools working
> against each other.
> 
> libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
> libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
> libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
> 
> Reading http://www.flameeyes.eu/autotools-mythbuster/autoconf/macros.html it
> suggests that ACLOCAL_AMFLAGS will be ignored in the future too, so
> libtool's suggestion is even more confusing.
> 
> As for AC_CONFIG_MACRO_DIRS, that doesn't appear to work on F18 yet, so we
> can't move this upstream yet, we want to build against all versions RHEL6
> and newer.

AC_CONFIG_MACRO_DIRS won't work until autoconf 2.70 is released upstream (I'm still working on that part).  But AC_CONFIG_MACRO_DIR will continue to work, and is NOT obsolete.

Whether or not automake should work when the AC_CONFIG_MACRO_DIR directory does not exist sounds like an unintentional automake regression, so this should be reported upstream to automake.

(In reply to comment #0)
> Description of problem:
> autoreconf -ivf calls aclocal --force, which checks the AC_CONFIG_MACRO_DIR.
> As of automake 1.13.1 this now fails if the directory is missing.
> 
> Package triggering this is xorg-x11-drv-wacom. The m4 directory is not
> present (it's empty, so not in git/tarball) and created by libtoolize.

Not having the m4 directory in git is solvable - merely do:
printf '*\n!.gitignore' > m4/.gitignore
then check in that file.

I seriously doubt you ship your tarball with no m4 directory, since the tarball is intended to work without people having to rerun automake or libtool, so the m4 directory in the tarball would already be populated.  So this is _just_ a problem for developing from git, and not with the final package.

Upstream bug filed: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13514

Upstream proposal:

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13514#29

Comments welcomed!

Pavel

Looks good to me.

(In reply to comment #9)
> Looks good to me.

I have pushed & built latest upstream fix for this issue:

http://git.savannah.gnu.org/cgit/automake.git/commit/?id=c83c133556205402d44e81d492efb0b2fe3e3584

It should fix problems with your xorg-* packages.

---

Just for future readers of this bug.  See the comment from Stefano Lattarini
http://lists.gnu.org/archive/html/bug-automake/2013-02/msg00046.html
for his suggestion to package maintainers (cite from mailing list):

  I'd suggest them to either:

  - use AC_CONFIG_MACRO_DIRS if they can/want require cutting-edge
    versions of the autotools;

  - use ACLOCAL_AMFLAGS otherwise, for the time being (until the
    now-cutting-edge autotools version have become widespread and
    "old" enough).

Another thing is that the local macro directory should be part of distribution
tarball (even if it is not in VCS) - 'make dist' should include it into
tarball.

Pavel