autoconf-patches
[Top][All Lists]
Advanced

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

Re: [PATCH 04/12] use a shell function for _AC_RUN_IFELSE


From: Eric Blake
Subject: Re: [PATCH 04/12] use a shell function for _AC_RUN_IFELSE
Date: Wed, 22 Oct 2008 17:59:08 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

Paolo Bonzini <bonzini <at> gnu.org> writes:

> 
> 2008-10-12  Paolo Bonzini  <bonzini <at> gnu.org>
> 
>       * lib/autoconf/general.m4 (_AC_RUN_IFELSE): Use a shell function.

> -_AC_MSG_LOG_CONFTEST
> -m4_ifvaln([$3],
> -       [( exit $ac_status )
> -$3])dnl])[]dnl
> -rm -rf conftest.dSYM
> -rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext 
conftest.$ac_objext m4_ifval([$1],
> -                                                  [conftest.$ac_ext])[]dnl
> +       _AC_MSG_LOG_CONFTEST
> +       ac_retval=$ac_status])
> +  rm -rf conftest.dSYM
> +  rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext 
conftest.$ac_objext conftest$ac_exeext

This is a subtle change in semantics; beforehand, the if-failed code ($3) was 
executed while the compiler output still existed, and could theoretically rerun 
conftest$ac_exeext with an argument; now the files are removed before the if-
failed code is run.  Was this intentional?  IMHO, it is a harmless change (I 
doubt anyone wrote an if-failed condition which was that closely tied to our 
undocumented internals, and even if they did, they are obviously so familiar 
with our internals that they should be able to compensate); and so far, in my 
testing with this applied, I haven't seen any packages hiccup.  At any rate, 
I'll wait another day before applying this, unless I get earlier agreement that 
this semantic change is okay (intended or not).

-- 
Eric Blake







reply via email to

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