[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AS_IF breakage
From: |
Ralf Wildenhues |
Subject: |
Re: AS_IF breakage |
Date: |
Tue, 14 Apr 2009 19:49:54 +0200 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
Hi Eric,
* Eric Blake wrote on Tue, Apr 14, 2009 at 05:39:33PM CEST:
> > Sorry for committing before the testsuite completed. It turns out that
> > this introduced a regression in 'make check TESTSUITEFLAGS="-k
> > AC_RUN_IFELSE"', due to the following:
> >
> > $ if false; then :; else echo $?; fi
> > 1
>
> In the process of trying to work around this, I discovered a bug in zsh 4.3.9:
>
> $ zsh -c 'emulate sh; false; $empty; echo $?'
> 1
Present in zsh 4.3.6, not present in zsh 4.3.4, BTW.
> Various things I've tried - the idea here is to replace 'echo $?' with
> anything
> else the user might have supplied, including an m4 macro that expands to the
> empty string:
[ lots of research snipped ]
Here's an idea: let's not be smarter than we can be.
> So, would we rather write:
[...]
> or revert today's patch to the simpler
>
> m4_define([_AS_IF_ELSE],
> [m4_ifnblank([$1],
> [else
> $1
> ])])
That is my favorite; along with not promising that we avoid shell syntax
errors at all costs.
> which puts the burden back on the user, where calling:
>
> AS_IF([false], [], [AC_REQUIRE(...)])
>
> causes a syntax error.
I think this is good enough. Such code is not written by very new
users, the error is unconditional and not silent, and as such is
uncovered during a simple test run of configure.
Adding `:;' to AC_REQUIRE is bound to bloat some configure scripts,
and as a result, can entice macro writers to not use AC_REQUIRE
consistently. Please do not do that. Besides, it doesn't fix the issue
for any other macro that expands to empty shell text, or a comment, such
as m4_require, m4_define, ...
> If I could get AC_REQUIRE to play nicely with m4_expand, then that would be
> the
> solution - pre-expand the user's text, at which point we then know for
> certain
> whether the expansion is empty. But right now, I don't know how to pull that
> trick off.
I agree.
Cheers, and thanks,
Ralf