---

5.9 The Future of aclocal

aclocal is expected to disappear. This feature really should not be offered by Automake. Automake should focus on generating Makefiles; dealing with M4 macros really is Autoconf’s job. That some people install Automake just to use aclocal, but do not use automake otherwise is an indication of how that feature is misplaced.

The new implementation will probably be done slightly differently. For instance it could enforce the m4/-style layout discussed in Handling Local Macros, and take care of copying (or even updating) third-party macro into this directory.

We have no idea when and how this will happen. This has been discussed several times in the past, but someone still has to commit itself to that non-trivial task.

From the user point of view, aclocal’s removal might turn out to be painful. There is a simple precaution that you may take to make that switch more seamless: never call aclocal yourself. Keep this guy under the exclusive control of autoreconf and Automake’s rebuild rules. Hopefully you won’t need to worry about things breaking, when aclocal disappears, because everything will have been taken care of. If otherwise you used to call aclocal directly yourself or from some script, you will quickly notice the change.

Many packages come with a script called bootstrap.sh or autogen.sh, that will just call aclocal, libtoolize, gettextize or autopoint, autoconf, autoheader, and automake in the right order. Actually this is precisely what autoreconf can do for you. If your package has such a bootstrap.sh or autogen.sh script, consider using autoreconf. That should simplify its logic a lot (less things to maintain, yum!), it’s even likely you will not need the script anymore, and more to the point you will not call aclocal directly anymore.