Re: testsuite.dir location

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Ralf Wildenhues on 6/16/2006 8:23 AM:
> Hello Eric,

Hi Ralf,

>> # Using `cd' in backquotes may print the directory name, use this instead:
>> m4__cd               = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
>> CD_TESTDIR   = abs_srcdir=`$(m4__cd) $(srcdir) && pwd`; cd tests
>> TESTSUITE = tests/testsuite
>>
>> check-local: tests/atconfig $(srcdir)/$(TESTSUITE)
>>      $(CD_TESTDIR); \
>>      $(TESTS_ENVIRONMENT) $(SHELL) $$abs_srcdir/$(TESTSUITE) \
>>              $(TESTSUITEFLAGS)
>>
>> but that dumps testsuite.log in the srcdir,
> 
> No, why would you think that?

A careless reading.  You are correct; the "cd tests" at the end of
CD_TESTDIR will change to the tests subdir relative to where make was run
(that is, once the CDPATH bug is fixed).

Speaking of which, does anyone know of a shell that violates the POSIX
requirement that "cd ./tests" skip the CDPATH search?  POSIX requires that
cd be silent when passed a relative path name anchored at ./, regardless
of whether CDPATH is set.

> 
> Well, CD_TESTDIR does two things: compute abs_srcdir, and "cd tests".
> It does not enter the source tree for the latter, unless you have a
> bug in your shell.

Or CDPATH set with . not first in the list.

> 
>> Is it worth adding a flag to testsuite to tell it which directory output
>> files should be dumped in?  Then I could tell m4's testsuite to create
>> testsuite.log in the tests subdirectory of the build dir.
> 
> Yes maybe, but it's close enough to a new feature and far enough from a
> critical bug that we can postpone this two weeks.

Agreed.  Which means this autoconf patch is also a candidate for post-2.60
(especially since I have not yet proven that it is portable):

2006-06-16  Eric Blake  <address@hidden>

        * doc/autoconf.texi (Special Shell Variables): Document that it is
        safe to do 'cd ./foo' regardless of CDPATH.

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEksPa84KuGfSFAYARAtG4AJwLBs4LfgAQ7xW7yZB7LU4cu5ZD7wCgzb0o
QZir4+8iW1RiAEfWanyru6U=
=CSCz
-----END PGP SIGNATURE-----

Index: doc/autoconf.texi
===================================================================
RCS file: /sources/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.1049
diff -u -p -r1.1049 autoconf.texi
--- doc/autoconf.texi   15 Jun 2006 13:20:05 -0000      1.1049
+++ doc/autoconf.texi   16 Jun 2006 14:39:54 -0000
@@ -11697,7 +11697,8 @@ Autoconf-generated scripts export this v
 @item CDPATH
 @evindex CDPATH
 When this variable is set it specifies a list of directories to search
-when invoking @code{cd} with a relative file name.  Posix
+when invoking @code{cd} with a relative file name that did not start
+with @samp{./} or @samp{../}.  Posix
 1003.1-2001 says that if a nonempty directory name from @env{CDPATH}
 is used successfully, @code{cd} prints the resulting absolute
 file name.  Unfortunately this output can break idioms like
@@ -11713,6 +11714,9 @@ In practice the shells that have this pr
 (unset CDPATH) >/dev/null 2>&1 && unset CDPATH
 @end example
 
+You can also avoid output by ensuring that your directory name is
+absolute or anchored at @samp{./}, as in @samp{abs=`cd ./src && pwd`}.
+
 Autoconf-generated scripts automatically unset @env{CDPATH} if
 possible, so you need not worry about this problem in those scripts.