For one of my project there was a bug report regarding
the project.m4 file that is going to be installed. So
far I did just use $datadir/aclocal of course - as it
is uncertain whether some `aclocal --print-ac-dir`
can be written to. Using a prefix-related default
happens to be gnu-style anyway. And it works for a
/usr package just fine using the /usr-installed
automake package.
However, there is hardly a way for a user-home
installation to extend this scheme - in other words,
there is a sysadmin-insallation of automake/aclocal
in prefix=/usr and a homedir-installation of an
add-on package in prefix=$HOME leading to an m4-file
ending up in $HOME/aclocal/.
That m4 file will be invisible to aclocal, and there
is no way that a path can be added - the aclocal 1.7
does read $datadir/aclocal/dirlist but that one is
a sysadmin file as well, not a user-home related file.
So far, the aclocal tool does not read any $HOME/*rc,
and it does neither check any $ENV{ACLOCALDIR} from the
shell environment as that could extend the sysadmin's
dirlist with a userhome dirlist.
This is very inconvenient - personally, I do have a
large installation of packages in my $HOME in some
workareas around, which includes a lot of libraries
that build on each other. When doing a change with
one of these, one might want to reconf the aclocal
macros as well. That requires to run always some
`aclocal -I $HOME/aclocal` simply because there is
no environment-variable that would add this option
automatically, e.g. ACLOCAL_OPTIONS="-I $HOME/acloal"
is this a bug or a feature?
It happens that there is no AUTOMAKE_OPTIONS environment
variable either to add default-options. In contrast, the
autoconf package knows a bunch of environment variables
to add/set directories that should be searched, and
the manual has an extra section about environment
variables.
-- guido http://zziplib.sf.net
(btw, $HOME/bin/aclocal script to shadow the sysadmin's
installation is the state-of-art AFAICS)
