Re: include bindir in AUTOM4TE default

[Alexandre Duret-Lutz]

[...]

 >> +2002-02-13  Alexandre Duret-Lutz  <address@hidden>
 >> +
 >> +   * doc/autoconf.texi (autoscan Invocation, autoconf Invocation,
 >> +   autoreconf Invocation, autoheader Invocation,
 >> +   autoupdate Invocation): Explain how sub commands such as autom4te
 >> +   are found, and how their location can be specified by the user.
 >> +   * bin/autoscan.in (bindir): New variable.
 >> +   (autom4te): Use it as prefix.
 >> +   * bin/autoheader.in: Likewise.
 >> +   * bin/autoupdate.in: Likewise.
 >> +   * bin/autoreconf.in (bindir): New variable.
 >> +   (autoconf, autoheader): Use it as prefix.
 >> +   * bin/autoconf.in (AUTOM4TE): Use $dir as prefix.
 >> +

It turns out this patch breaks the test-suite.  (In short: the
test-suite adds tests/ directory to $PATH so it uses the auto*
wrapper in that directory, and the wrappers in this directory
call the real auto* scripts with their full pathname.  This
patch causes the real auto* scripts to call the other real auto*
script instead of the wrappers; hence Autoconf, for instance,
uses the m4 files from the previously installed version.)

It took me a while to figure out what was happening (until Akim
eventually came to the rescue).  Although the test-suite could
be patched to support this new searching order (e.g. by
computing and exporting AUTOM4TE, AUTOCONF, etc.), I'm now
convinced the above patch is a very bad idea.

Auto* scripts _have_ to be searched in path, the Autoconf
test-suite is an example of how stuck you can get if it's not the
case.  Another evidence of why Autoconf needs to be in path are
the Makefile rebuild rules for configure: they can't work
otherwise.

The only solutions I see to allow parallel installations of
Autoconf in the same $prefix are the one used by CVS Automake
(version the filename) or that from GCC (support -V version).
-- 
Alexandre Duret-Lutz