autoconf-patches
[Top][All Lists]
Advanced

[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




reply via email to

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