Re: hardcoded prefix in aclocal

[Jim Meyering]

Brian Cameron <address@hidden> wrote:
| Thanks for the excellent suggestion.  However, it still would be best
| if the aclocal Perl program were updated to use "$0" to calculate where
| the "share" directory is located ("$0" should contain the path to the
| bin directory and the share directory is just ../share from there).

No.  IMHO it should not do that.
If it does that, then the binary will work differently depending
on where it resides when you run it.  That will cause grief for some
installations.  For example, if I currently configure each new version with
--prefix=/whatever/autoconf-$(date +%Y-%m-%d.%Hh%M) and install,
then simply create links to /whatever/autoconf-$(date +%Y-%m-%d.%Hh%M)/bin/*
from some directory in my path, my method will no longer work because
the script will determine where to look based on $0 rather than on
the prefix specified at configure-time.

Why not just use aclocal's `-I include_dir' option?

| The reason we are setting up the symbolic link directory structure
| is because we have multiple projects that each require different
| versions of the GNU utilities for stable testing purposes.  Therefore
| we would like to create several trees of symbolic links pointing to
| the actual applications.  This is defeated when a program like
| aclocal uses a hardcoded path to look for files that are installed
| by other programs.
|
| Therefore manipulating the "--prefix" value doesn't work for our
| environment.  However, we are getting around it by hacking our own
| environment variable into the aclocal script instead of using the
| "$prefix" variable.  It works for now, but it is a hack.  I submitted
| a bug to the automake gnats database, so I hope aclocal is made just
| a little smarter.