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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 7988 in the body.
You can then email your comments to 7988 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Peter Johansson <trojkan <at> gmail.com>
To: bug-automake <at> gnu.org
Subject: the manual suggests installing macro files to hard-coded location
Date: Sat, 05 Feb 2011 00:19:19 -0500

[Message part 1 (text/plain, inline)]

Hello,

In the manual, 
http://sources.redhat.com/automake/automake.html#Invoking-aclocal,
I read about the `--print-ac-dir' option:

Prints the name of the directory that |
|aclocal will search to find third-party .m4 files. When this option is 
given, normal processing is suppressed. This option can be used by a 
package to determine where to install a macro file.

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). IIUC that
that contradicts the discussion in section "Install to Hard-Coded Locations"

http://sources.redhat.com/automake/automake.html#Hard_002dCoded-Install-Paths

Cheers,
Peter

[Message part 2 (text/html, inline)]

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Peter Johansson <trojkan <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 13:36:28 +0100

On Saturday 05 February 2011, Peter Johansson wrote:
> Hello,
> 
Hello Peter, and sorry for the terrible delay.

> In the manual, 
> http://sources.redhat.com/automake/automake.html#Invoking-aclocal,
> I read about the `--print-ac-dir' option:
> 
> ``Prints the name of the directory that aclocal will search to find
>   third-party .m4 files. When this option is given, normal processing
>   is suppressed. This option can be used by a package to determine
>   where to install a macro file.''
> 
> 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>

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?)

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

> IIUC that that contradicts the discussion in section "Install to
> Hard-Coded Locations"
>
> http://sources.redhat.com/automake/automake.html#Hard_002dCoded-Install-Paths
> 
> Cheers,
> Peter
> 

Thanks,
   Stefano

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

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Peter Johansson <trojkan <at> gmail.com>
Cc: 7988 <at> debbugs.gnu.org
Subject: Re: bug#7988: the manual suggests installing macro files to
	hard-coded location
Date: Wed, 28 Sep 2011 12:47:13 +0200

[Message part 1 (text/plain, inline)]

On Sunday 20 March 2011, Peter Johansson wrote:
> Hello Stefano,
> 
> On 3/19/11 8:36 AM, Stefano Lattarini wrote:
> >
> > 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
> 
OK, now we have ACLOCAL_PATH support implemented into maint, so it's time to
fix this bug.  I'll push the attached patch to maint in a couple of days if
there is no objection.

Regards,
  Stefano

[0001-docs-don-t-suggest-installing-.m4-files-in-hard-code.patch (text/x-patch, inline)]

From b100d18da312f4b22be283b9a877b221667b2245 Mon Sep 17 00:00:00 2001
Message-Id: <b100d18da312f4b22be283b9a877b221667b2245.1317206773.git.stefano.lattarini <at> gmail.com>
From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Date: Sun, 25 Sep 2011 14:29:19 +0200
Subject: [PATCH] docs: don't suggest installing `.m4' files in hard-coded location

This change fixes automake bug#7988.

* doc/automake.texi (aclocal Options): State that the use of
the `--print-ac-dir' option to determine the directory where
third-party packages can install their `.m4' files is discouraged
now.
(Extending aclocal): Suggest telling the user about ACLOCAL_PATH.
* THANKS: Update.

Report by Peter Johansson.
---
 ChangeLog         |   12 ++++++++++++
 THANKS            |    1 +
 doc/automake.texi |   17 +++++++++++++----
 3 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 47aee92..12cdb6e 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,15 @@
+2011-09-28  Stefano Lattarini  <stefano.lattarini <at> gmail.com>
+
+	docs: don't suggest installing `.m4' files in hard-coded location
+	This change fixes automake bug#7988.
+	* doc/automake.texi (aclocal Options): State that the use of
+	the `--print-ac-dir' option to determine the directory where
+	third-party packages can install their `.m4' files is discouraged
+	now.
+	(Extending aclocal): Suggest telling the user about ACLOCAL_PATH.
+	* THANKS: Update.
+	Report by Peter Johansson.
+
 2011-09-22  Stefano Lattarini  <stefano.lattarini <at> gmail.com>
 
 	tests: fix tests on aclocal search path precedences
diff --git a/THANKS b/THANKS
index f83e1fc..3c106c7 100644
--- a/THANKS
+++ b/THANKS
@@ -275,6 +275,7 @@ Per Oyvind Hvidsten	poeh <at> enter.vg
 Peter Breitenlohner	peb <at> mppmu.mpg.de
 Peter Eisentraut	peter_e <at> gmx.net
 Peter Gavin		pgavin <at> debaser.kicks-ass.org
+Peter Johansson		trojkan <at> gmail.com
 Peter Mattis		petm <at> scam.XCF.Berkeley.EDU
 Peter Muir		iyhi <at> yahoo.com
 Peter O'Gorman		peter <at> pogma.com
diff --git a/doc/automake.texi b/doc/automake.texi
index a8233dd..c463fe7 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -3254,8 +3254,12 @@ Cause the output to be put into @var{file} instead of @file{aclocal.m4}.
 @opindex --print-ac-dir
 Prints the name of the directory that @command{aclocal} will search to
 find third-party @file{.m4} files.  When this option is given, normal
-processing is suppressed.  This option can be used by a package to
-determine where to install a macro file.
+processing is suppressed.  This option was used @emph{in the past} by
+third-party packages to determine where to install @file{.m4} macro
+files, but @emph{this usage is today discouraged}, since it causes
+@samp{$(prefix)} not to be thoroughly honoured (which violates the
+GNU Coding Standards), and a similar semantics can be better obtained
+with the @env{ACLOCAL_PATH} environment variable; @pxref{Extending aclocal}.
 
 @item --verbose
 @opindex --verbose
@@ -3430,6 +3434,7 @@ Similarly, @file{dirlist} can be handy if you have installed a local
 copy of Automake in your account and want @command{aclocal} to look for
 macros installed at other places on the system.
 
+@anchor{ACLOCAL_PATH}
 @subsubheading Modifying the Macro Search Path: @file{ACLOCAL_PATH}
 @cindex @env{ACLOCAL_PATH}
 
@@ -3491,8 +3496,12 @@ aclocal_DATA = mymacro.m4 myothermacro.m4
 
 @noindent
 Please do use @file{$(datadir)/aclocal}, and not something based on
-the result of @samp{aclocal --print-ac-dir}.  @xref{Hard-Coded Install
-Paths}, for arguments.
+the result of @samp{aclocal --print-ac-dir} (@pxref{Hard-Coded Install
+Paths}, for arguments).  It might also be helpful to suggest to
+the user to add the @file{$(datadir)/aclocal} directory to his
+@env{ACLOCAL_PATH} variable (@pxref{ACLOCAL_PATH}) so that
+@command{aclocal} will find the @file{.m4} files installed by your
+package automatically.
 
 A file of macros should be a series of properly quoted
 @code{AC_DEFUN}'s (@pxref{Macro Definitions, , , autoconf, The
-- 
1.7.2.3

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

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Peter Johansson <trojkan <at> gmail.com>
Cc: 7988-done <at> debbugs.gnu.org
Subject: Re: bug#7988: the manual suggests installing macro files to
	hard-coded location
Date: Sat, 1 Oct 2011 19:29:09 +0200

On Wednesday 28 September 2011, Stefano Lattarini wrote:
> OK, now we have ACLOCAL_PATH support implemented into maint, so it's time to
> fix this bug.  I'll push the attached patch to maint in a couple of days if
> there is no objection.
> 
> Regards,
>   Stefano
> 
Pushed now.  I'm thus closing this bug report.

Regards,
  Stefano

Previous Next

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