On Saturday 05 February 2011, Peter Johansson wrote: > Hello, > Hello Peter, and sorry for the terrible delay.
> In the manual, > http://sources.redhat.com/automake/automake.html#Invoking-aclocal, > I read about the `--print-ac-dir' option: > > ``Prints the name of the directory that aclocal will search to find > third-party .m4 files. When this option is given, normal processing > is suppressed. This option can be used by a package to determine > where to install a macro file.'' > > I find the last sentence a bit strange because to me that sounds like > Automake suggests that packagers should install macro files in a > hard-coded directory not relative to $(prefix). > Yes, this is exactly what it suggests. Unfortunately, this is currently the best way to allow aclocal to find the installed third-pary macro file; for more information see: <http://www.gnu.org/software/automake/manual/html_node/Macro-Search-Path.html> Another viable approach would be to install the third-party macro file in `$(third-party-prefix)/share/aclocal', and then extend the file `$(aclocal-prefix)/share/aclocal/dirlist' to list that directory too; but this would mean *modify* a possibly pre-existing file (and in a hard-coded location too), and I'm not sure this is a wise move (but maybe might be worth citing in the documentation anyway... Opinions?) Finally, note that this problem should be ameliorated once the pending patches introducing support for the ACLOCAL_PATH environment variable are merged: <http://lists.gnu.org/archive/html/automake-patches/2010-11/msg00089.html> At that point, a thid-party package providing macro files can install them into `$(third-party-prefix)/share/aclocal', and then tell the user to extend the system-wide definition of ACLOCAL_PATH accordingly (somewhat similarly to what libtool install rules does with `LD_LIBRARY_PATH'). > IIUC that that contradicts the discussion in section "Install to > Hard-Coded Locations" > > http://sources.redhat.com/automake/automake.html#Hard_002dCoded-Install-Paths > > Cheers, > Peter > Thanks, Stefano
