bug#9026: Supporting $ACLOCAL_PATH?

[Stefano Lattarini]

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