Re: Fixes for builddir != srcdir

[Akim Demaille]

| Hi,

Hi!

| The following patch makes it possible to use the testsuite in a
| non-srcdir build. 

I don't exactly agree on the terms you use here: your changes are
making it possible for the maintainer to keep her src/build trees
separate, but a regular user has strictly no problems running the test
suite with src != build.


| While testing autoupdate:
|  
|   * autoupdate calls 'autoconf -i --trace ...'
|   * autoconf looks for autoconf.m4
|   * $autoconf_dir = .., which is in the build directory, and so
|     autoconf cannot find autoconf.m4

Arg, indeed this is a bad one.  autoconf.m4 and autoconf.m4f can be in
different directories, I never thought about this issue.

| Part 1 of solution: Use $top_srcdir as $autoconf_dir
|  
| However,
|  
|   * autoconf.m4 includes acversion.m4, which is not in the source dir
|   * acversion.m4 needs only be built by the maintainer
|   * The current Makefiles will fail on distcheck due to acversion.m4 
|     being in the builddir.
|  
| Part 2 of solution: Put acversion.m4 in $srcdir.  (While at it, put
| created INSTALL.txt in $srcdir too.)
|  
| With these changes, the testsuite has only 5 fails.  4 are the
| expected failures with autoupdate.  The other is a g77 problem for
| which I'll file a separate bugreport.

It seems a lot of hair to me (new Make rules for something which is
quite logically under the responsibility of configure etc.).  But I'd
like the opinion of other maintainers.  Personally I would not fight
to be able to maintain Autoconf with src != build, while it is
important on the user side, agreed.


Personally it seems to me we should open a back door to these tools to
have them ready to work with autoconf.m4 in a different directory than
autoconf.m4f.  In fact, using the -I feature of GNU M4 makes this
trivial (but I'd like to avoid depending on such feature :)