[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: testsuite.dir location

From: Eric Blake
Subject: Re: testsuite.dir location
Date: Fri, 16 Jun 2006 08:44:43 -0600
User-agent: Thunderbird (Windows/20060516)

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
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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]