Re: Ping: add $srcdir/../../.. to toplevel search path

[Alexandre Duret-Lutz]

>>> "Kelley" == Kelley Cook <address@hidden> writes:

 >> 
 >> > Hello,
 >> > Just a ping of this simple patch from 2 weeks ago.
 >> 
 >> I'm not aware that this patch was applied in Automake.

Well, I was waiting to see what you'd do in Autoconf :)

 Kelley> The proposed automake patch

 Kelley> http://article.gmane.org/gmane.comp.sysutils.automake.patche
 Kelley> s/1001

 Kelley> is just a documentation patch describing the additional
 Kelley> directory level for AC_CONFIG_AUX_DIR_DEFAULT that my
 Kelley> proposed autoconf patch adds.

Actually Automake would need more changes if Autoconf goes this
way.  This search path is hard-coded in Automake
(see @config_aux_path -- Akim, do you think we should trace
AC_CONFIG_AUX_DIR_DEFAULT?) and also documented in its manual.


Out of curiosity, is this search path really useful?  When a
subpackage is using the aux scripts from an outer package, you
cannot run `make dist' anymore in the sub-package (or maybe only
`make distcheck' fails, I don't remember).  IMO, having `make
dist' working in subpackages is more important than saving a few
bytes by sharing scripts (but probably I'm missing the true
intent of this search path, hence my question).

Over the past months the Automake lists have received a couple
of mails from people asking why `automake -i' would not install
install-sh in their subprojects, and why they could not run
`make dist' successfully in these subprojects.  The solution, of
course, is to disable this searching by using AC_CONFIG_AUX_DIR
(even a simple AC_CONFIG_AUX_DIR(.)).  But it shows that people
are not aware of this search path: it's a pitfall.  Adding
another directory to this hidden list sounds like enlarging the
trap.  On the other hand, maybe `make dist' could be fixed to
copy these files locally, I don't know.
-- 
Alexandre Duret-Lutz