aclocal ¶Ideally, aclocal should not be part of Automake. Automake
should focus on generating Makefiles; dealing with M4 macros is
more Autoconf’s job. The fact that some people install Automake just
to use aclocal, but do not use Automake otherwise, is an
indication of how that feature is misplaced.
A new implementation would probably be done slightly differently. For instance, it could enforce the m4/-style layout discussed in Handling Local Macros.
We do not know when or whether this will happen. It has been discussed several times, but someone still has to commit to executing this non-trivial task.
From the user’s 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 its invocation 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 or
autogen.sh that calls aclocal, libtoolize,
gettextize or autopoint, autoconf,
autoheader, and automake in the right order. In
fact, this is precisely what autoreconf can do for you. If
your package has such a bootstrap or autogen.sh script,
consider using autoreconf. That should simplify its logic
(all to the good), and more to the point you will not call
aclocal directly anymore.
For the time being, third-party packages should continue to install
public macros into /usr/share/aclocal/. If aclocal
is replaced by another tool it might make sense to rename the
directory, but supporting /usr/share/aclocal/ for backward
compatibility should be feasible, provided all macros are properly
written (see Writing your own aclocal macros).