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
aclocal, but do not use
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.
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 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
Keep this guy under the exclusive control of
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 will just call
the right order. In fact, this is precisely what
can do for you. If your package has such a bootstrap or
autogen.sh script, consider using
should simplify its logic a lot (less things to maintain, all to the
good), it’s even likely you will not need the script anymore, 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
is replaced by another tool it might make sense to rename the
directory, but supporting /usr/share/aclocal/ for backward
compatibility should be easy provided all macros are properly written
(see Writing your own aclocal macros).