GNU bug report logs - #7988
the manual suggests installing macro files to hard-coded location

Previous Next

Full log

Message #11 received at 7988 <at> debbugs.gnu.org (full text, mbox):

From: Peter Johansson <trojkan <at> gmail.com>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 7988 <at> debbugs.gnu.org
Subject: Re: bug#7988: the manual suggests installing macro files to hard-coded
	location
Date: Sat, 19 Mar 2011 22:26:57 -0400

Hello Stefano,

On 3/19/11 8:36 AM, Stefano Lattarini wrote:
> On Saturday 05 February 2011, Peter Johansson wrote:
>
>> 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>
>
With the same logic, the best way to intall header files would be to ask 
gcc about its search path and intall header files where gcc will find 
them - typically in `/usr/local/include'.

I think this would be suboptimal and a better way to do it is to install 
headers in `$(includedir)' and have this set to `${prefix}/include' as 
default but also give the installer the freedom to change this location 
if desired at configure time or even at make time.

IMVHO, that approach works also for m4 files. Install m4 files in 
`$(aclocaldir)', whose default value is `${datadir}/aclocal'. If that 
happens to be a place aclocal never heard of, the user can always supply 
'-I' flags as needed.

On one system at work I have aclocal installed in `/usr/bin/' and since 
I'm not root I can not install stuff into `/usr' and would find it 
annoying if packages insisted on installing m4 files into 
`/usr/share/aclocal' although I configure with `--prefix=$HOME'. And on 
top of that distcheck typically fails if one tries to install things to 
a location outside the $(prefix) tree.


> 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?)
>
IMVHO that doesn't sound like an improvement. Say that I, e.g., install 
an old version of GSL with --prefix=/usr/local/gsl-1.6. That doesn't 
mean I want aclocal to look for m4 files in 
`/usr/local/gsl-1.6/share/aclocal'. And what happens with all the times 
I install my own package within distcheck, would that prefix 
(`pwd`/_inst) also be added in `dirlist'?

> 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').

Sounds good.

Thanks,
Peter

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.