[Top][All Lists]
[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