[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#7988: the manual suggests installing macro files to hard-coded locat

From: Peter Johansson
Subject: bug#7988: the manual suggests installing macro files to hard-coded location
Date: Sat, 19 Mar 2011 22:26:57 -0400
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv: Gecko/20110303 Thunderbird/3.1.9

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:

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:
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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]