Re: [RFA] Validate configure script syntax

[Akim Demaille]

 >> I have avoided AS_REQUIRE on purpose in the case of Autotest: the
 >> point is that (when someone has some spare time) we can extract a
 >> small test script focusing on the exact failure.  This is what pleases
 >> people having test suites a` la Automake.  We should be able to
 >> provide this to them.  I don't think AS_REQUIRE fits in the picture.

 > Ok.  I'll document it when I come to documenting AS_REQUIRE. :-)

 > Ahem, does not this go against using shell functions in Autotest? >:->

Not for the functions that ensure the Autotest infrastructure.  The
case of user shell functions is different, and I guess the best would
be to have some form of atlocal for functions.  We should provide the
user with a means to add some content to a generic file, shared across
test cases.


 >> What is the impact on the duration of the test suite?

 > The slowdown is not much, but both the speed and the testsuite size would be
 > improved by adding a separate AT_CHECK_CONFIGURE_SYNTAX macro and using it
 > specially for tests that do not run configure (if any).  Configure scripts
 > are run without exiting earlier, so given how shell scripts are parsed, I
 > don't think it is so frequent that sh -n catches more errors than an actual
 > run. 

Actually some syntax errors are not caught by a mere execution.
That's actually why these checks where added for Autoconf's own
scripts: some paths were not exercised by the test suite itself.

 > And configure runs config.status so unless it exits early (does
 > it?)  there's no point in checking config.status syntax after it
 > has run.  So I put this in the "to be thought more on" category.

 > I wanted to commit only the part to extract AT_CHECK_SHELL_SYNTAX
 > (without AS_REQUIRE) and AT_CHECK_PERL_SYNTAX out of tools.at, 

That's OK.

 > but subversions.gnu.org is down, so I'll ask another question in
 > the meanwhile... is there anything wrong in this alternative
 > detection method?

 >     if test x"`echo echo yes | sh -n 2>&1`" = x; then
 >       echo ok
 >     else
 >       echo bad;
 >     fi

I don't know :)  Sounds OK, but the problem is to catch shells that
loop on checking loops.