Re: hardcoded prefix in aclocal

[Brian Cameron]

Jim:

> | > Why not just use aclocal's `-I include_dir' option?
> |
> | Since calls to automake are often buried, it would be time consuming to
> | find & fix all places where this issue is a problem.  We are using automake
> | to build the 40 or so packages that make up Gnome, so finding each place
> | where I need to add an '-I' is prohibitive.
> 
> Then how about invoking make like this:
> 
>   make ACLOCAL='aclocal -I /path/to/your/private/m4/directory'

Well, as I stated in my earlier email there are a number of 
workarounds that I can use to get around the issue.  Remembering
and correctly typing the above make invocation is an ambitious
suggestion.  I still think that using a hardcoded path in aclocal
is limiting.

For example, if I decide I want to move autoconf to a new location
(lets say I move /usr/local to /opt/local), then it is necessary for
me to re-run configure, rebuild the application and re-install it with
the updated prefix.  I have a similar problem if I want to access 
autoconf via an automount that doesn't (or can't) exactly match the
prefix value (let's say I already have a "/usr/local" on my machine
so I would like to mount the "/usr/local" of another machine with
autoconf to a different directory on my machine).  My situation of
using symbolic links described in my previous email is just another
way that he hardcoded value for $prefix in the aclocal program can
become stale.  

My interest in bringing up this issue is to suggest making automake
more robust rather than to correct any immediate problem I am having.
It seems that there should be a more elegant solutions than making the
user manually enter "-I" option(s).  The idea I proposed of using
"$0" is a suggestion, another suggestion is to use an environment
variable that the user can define.  Not being very familiar with 
automake, I suspect even more elegant solutions are possible.
Clearly automake would be a more powerful tool if it did not break
in situations like the ones described above where it could recover.

Brian