bug#9026: Supporting $ACLOCAL_PATH?
Hi Bruno,
On 7/8/11 5:24 PM, Bruno Haible wrote:
+If you are using GNU @code{automake} 1.10 or newer, it is even easier:
+Add the line
+
+@example
+ACLOCAL_AMFLAGS = --install -I m4
+@end example
+
+@noindent
+to your top level @file{Makefile.am}, and run @samp{aclocal --install -I m4}.
+This will copy the needed files to the @file{m4/} subdirectory automatically,
+before updating @file{aclocal.m4}.
+
I used to do this as it is an easy way to stay up to date with 3rd party
m4 files. I stopped doing this, however, after Ralf Wildenhues made me
aware there is a risk doing so. The risk is that aclocal will copy 3rd
party m4 files into m4 not only for you but also for your users if they
happen to run aclocal. Say, e.g., that a user want to build a somewhat
old version of your package from git; he bootstraps and as he has newer
versions of the m4 files available on his system aclocal copies them
into m4, which may cause problems as they are not necessarily compatible
with your configure.ac. To avoid this from happen, I've removed the
--install flag from my packages and calls aclocal --install -I m4
frequently instead.
There is, obviously, a risk doing this way, as mentioned above in this
thread, because if I'm not careful I may release a tarball with missing
m4 files. Would distcheck detect a missing m4 file, or would it be
possible to modify distcheck so it could warn about this case?
Cheers,
Peter
bug#9026: Supporting $ACLOCAL_PATH?
Hello, On an FHS-style system, all macros are picked up from /usr/share/aclocal. Conversely, on a Stow/Nix-style installation, macros are to be found in /foo/automake/share/aclocal, /bar/guile/share/aclocal, /baz/pkg-config/share/aclocal, etc. It seems to me that the latter calls for user environment-specific settings, which an $ACLOCAL_PATH environment variable would handily support [0]. WDYT? Bruno rightfully noted the importance of having a reproducible way of producing tarballs, and user-specific environment settings appear to go counter this goal. However, there will always be a need for this kind of setting on Stow/Nix-style systems, AFAICS. Thanks, Ludo’. [0] In fact Nixpkgs/NixOS has a wrapper around ‘aclocal’ that does exactly this (see https://svn.nixos.org/repos/nix/nixpkgs/trunk/pkgs/development/tools/misc/automake/builder.sh.)
bug#9026: Supporting $ACLOCAL_PATH?
tags 9026 patch thanks On Friday 08 July 2011, Ludovic Courtès wrote: Hello, Hi Ludovic, thanks for the report. On an FHS-style system, all macros are picked up from /usr/share/aclocal. Conversely, on a Stow/Nix-style installation, macros are to be found in /foo/automake/share/aclocal, /bar/guile/share/aclocal, /baz/pkg-config/share/aclocal, etc. It seems to me that the latter calls for user environment-specific settings, which an $ACLOCAL_PATH environment variable would handily support [0]. WDYT? Bruno rightfully noted the importance of having a reproducible way of producing tarballs, and user-specific environment settings appear to go counter this goal. However, there will always be a need for this kind of setting on Stow/Nix-style systems, AFAICS. Thanks, Ludo’. [0] In fact Nixpkgs/NixOS has a wrapper around ‘aclocal’ that does exactly this (see https://svn.nixos.org/repos/nix/nixpkgs/trunk/pkgs/development/tools/misc/automake/builder.sh.) JFTR, there's a pending patch series by Paolo Bonzini that introduces exactly the feature you're requesting: http://lists.gnu.org/archive/html/automake-patches/2010-11/msg00089.html I'm highly in favor of having the series applied to maint ASAP, but we should wait for Ralf's ACK before doing that (and probably he won't be avaiable this weekend). Regards, Stefano
bug#9026: Supporting $ACLOCAL_PATH?
Ludovic Courtès wrote: ... having a reproducible way of producing tarballs, and user-specific environment settings appear to go counter this goal. Not only that. Also, it is important for distributors to be able to regenerate the 'configure' file of packages, for a variety of reasons. They can only do so if the tarball contains the _complete_ source code of the configure file, that is, all the .m4 files that were used to create it, except the .m4 files of Automake and Autoconf. Have you ever tried to rebuild the configure file of a package that did not package pkgconfig.m4 or glib.m4? It's a nightmare. Therefore, please don't encourage maintainers to omit nontrivial .m4 files from the tarball. Adding support $ACLOCAL_PATH would do exactly that. Bruno -- In memoriam Jean Moulin http://en.wikipedia.org/wiki/Jean_Moulin
bug#9026: Supporting $ACLOCAL_PATH?
Hi Bruno. On Friday 08 July 2011, Bruno Haible wrote: Ludovic Courtès wrote: ... having a reproducible way of producing tarballs, and user-specific environment settings appear to go counter this goal. Not only that. Also, it is important for distributors to be able to regenerate the 'configure' file of packages, for a variety of reasons. They can only do so if the tarball contains the _complete_ source code of the configure file, that is, all the .m4 files that were used to create it, except the .m4 files of Automake and Autoconf. Have you ever tried to rebuild the configure file of a package that did not package pkgconfig.m4 or glib.m4? It's a nightmare. Therefore, please don't encourage maintainers to omit nontrivial .m4 files from the tarball. Adding support $ACLOCAL_PATH would do exactly that. Following your line of thinking, we should also drop the support for the `dirlist' special file then. The fact that a feature can be misused is IMHO not a good reason against its introduction, if it can also be used legitimately and profitably. Also, a conscientious user would anyway add `--install -I m4' to his ACLOCAL_AMFLAGS, so that third-party m4 files would be copied in the local m4 directory (and thus automatically distributed by automake). I say we should instead follow the UNIX practice of giving the user enough rope to hang himself, but advise him not to do so; metaphors aside, this means we should implement $ACLOCAL_PATH, but also vouch your concerns clearly and strongly in the manual (as usual, patches welcome ;-) Regards, Stefano
bug#9026: Supporting $ACLOCAL_PATH?
Hi Stefano, I say we should instead follow the UNIX practice of giving the user enough rope to hang himself, but advise him not to do so This is a good attitude for the many features with which a developer can only harm himself and which cause no harm to others. But with $ACLOCAL_PATH he can harm the freedom of the distributors of his package; I think this requires special consideration. Bruno -- In memoriam Jean Moulin http://en.wikipedia.org/wiki/Jean_Moulin
bug#9026: Supporting $ACLOCAL_PATH?
Hi Stefano,
Also, a conscientious user would anyway add
`--install -I m4' to his ACLOCAL_AMFLAGS, so that third-party m4 files
would be copied in the local m4 directory (and thus automatically
distributed by automake).
Hey, the --install option is something I need to mention in the GNU gettext
documentation. I wasn't aware of it up to now.
2011-07-08 Bruno Haible br...@clisp.org
* gettext.texi (aclocal): Recommend the use of aclocal's --install
option.
Suggested by Stefano Lattarini stefano.lattar...@gmail.com.
--- gettext-tools/doc/gettext.texi.orig Fri Jul 8 23:22:44 2011
+++ gettext-tools/doc/gettext.texi Fri Jul 8 23:22:39 2011
@@ -7990,6 +7990,18 @@
@noindent
to your top level @file{Makefile.am}.
+If you are using GNU @code{automake} 1.10 or newer, it is even easier:
+Add the line
+
+@example
+ACLOCAL_AMFLAGS = --install -I m4
+@end example
+
+@noindent
+to your top level @file{Makefile.am}, and run @samp{aclocal --install -I m4}.
+This will copy the needed files to the @file{m4/} subdirectory automatically,
+before updating @file{aclocal.m4}.
+
These macros check for the internationalization support functions
and related informations. Hopefully, once stabilized, these macros
might be integrated in the standard Autoconf set, because this
--
In memoriam Jean Moulin http://en.wikipedia.org/wiki/Jean_Moulin
