Paolo Bonzini wrote:
>> Right. Might want to explicitly discourage touching those variables.
>> (This is hopefully not common today, but probably not so uncommon in
>> legacy code.)
>
> I'll look at
>
> http://www.google.com/codesearch?q=ac_(compile|link|cpp)%3D+file%3Aconfigure.ac
> http://www.
> Right. Might want to explicitly discourage touching those variables.
> (This is hopefully not common today, but probably not so uncommon in
> legacy code.)
I'll look at
http://www.google.com/codesearch?q=ac_(compile|link|cpp)%3D+file%3Aconfigure.ac
http://www.google.com/codesearch?q=ac_(compi
* Paolo Bonzini wrote on Fri, Oct 17, 2008 at 09:14:20AM CEST:
>
> But the only arguments in the eval *when the eval appears in shell
> functions* (I don't care about user code relying on _AC_DO, because it
> will appear outside functions) are:
>
> $ac_cpp
> $ac_compile
> $ac_link
> ./con
>> Do you think that:
>>
>> (eval "$ac_link") 2>&5
>> ac_status=$?
>> (eval "$ac_try") 2>&5
>> ac_status=$?
>>
>>
>> are portable?
>
> Pretty likely not:
>
> $ zsh --version
> zsh 4.2.3 (powerpc-apple-darwin8.0)
> $ zsh
> $ f () { ( exit 1); echo $?; }; f
> 0
> $ f ()
Ralf Wildenhues wrote:
> * Paolo Bonzini wrote on Mon, Oct 13, 2008 at 11:59:22AM CEST:
>> You will remember the shell function portability issue in zsh...
>
> Yes; sigh.
>
>> Do you think that these functions: [...]
>> are portable? (Yeah, the code is totally unreadable).
>
> Pretty likely no
* Paolo Bonzini wrote on Mon, Oct 13, 2008 at 11:59:22AM CEST:
> You will remember the shell function portability issue in zsh...
Yes; sigh.
> Do you think that these functions:
reindented to:
ac_func_c_try_compile()
{
rm -f conftest.$ac_objext
if
{
(ac_try="$ac_compile"
ca
