[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AC_TRY_COMPILE() annoyances with 2.63b
From: |
Eric Blake |
Subject: |
Re: AC_TRY_COMPILE() annoyances with 2.63b |
Date: |
Mon, 06 Apr 2009 20:25:12 -0600 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090302 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to Mike Frysinger on 4/6/2009 3:43 PM:
>>> m4_define([_AS_IF_ELSE],
>>> [m4_ifvaln([$1],
>>> -[else
>>> +[else :
>>> $1])])
>>>
>>> m4_defun([AS_IF],
>> I like this one, for simplicity and obvious correctness alone, but will
>> defer to Eric for the final decision.
>
> personally, i prefer both :). dont emit extraneous brackets when they arent
> needed, and be safe when we think we must.
I'm also leaning towards omitting the else if $1 is provably blank,
otherwise providing the : in case non-blank $1 ultimately expands to a
blank (unless someone finds a shell where 'if false ; then :; fi; echo $?'
fails to output 0). AS_CASE and AS_FOR are also candidates for this. And
it will be easier with m4_ifblank. Stay tuned; I'll have a patch by the
end of the week.
Now for a question - right now, m4_default([$1], [$2]) is a nice shorthand
for m4_ifval([$1], [$1], [$2]); is there any reason to create a shorthand
for m4_ifnblank([$1], [$1], [$2]) that likewise only needs two arguments?
And if so, what to call it?
>> BTW, m4_normalize would have been wrong as it can change expanded text
>> that you wouldn't want changed, too. (I think.)
>
> but that wouldnt matter would it ? we're only expanding to check it
> ifvaln(normalize($1)). if we like the result, then we emit $1 as part of the
> else. but again, m4 subtleties are beyond me.
Actually, you nailed the subtleties on that one:
m4_ifval(m4_normalize([$1]), [else :
$1
])
uses two copies of $1; the first can undergo arbitrary change to check for
blanks, while the second is used as-is. I'd use exactly that if it
weren't for the fact that the future m4_ifblank is more efficient than
m4_ifval/m4_normalize.
- --
Don't work too hard, make some time for fun as well!
Eric Blake address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAknauYgACgkQ84KuGfSFAYAW0wCcCdQaXVK+3zkxA1fQ15DDca2E
Q8YAn1NVAGo58KaUumgZgemx75Fjk3Ea
=tBx2
-----END PGP SIGNATURE-----
- AC_TRY_COMPILE() annoyances with 2.63b, Mike Frysinger, 2009/04/05
- Re: AC_TRY_COMPILE() annoyances with 2.63b, Eric Blake, 2009/04/05
- Re: AC_TRY_COMPILE() annoyances with 2.63b, Mike Frysinger, 2009/04/05
- Re: AC_TRY_COMPILE() annoyances with 2.63b, Mike Frysinger, 2009/04/05
- Re: AC_TRY_COMPILE() annoyances with 2.63b, Eric Blake, 2009/04/06
- Re: AC_TRY_COMPILE() annoyances with 2.63b, Mike Frysinger, 2009/04/06
- Re: AC_TRY_COMPILE() annoyances with 2.63b, Ralf Wildenhues, 2009/04/06
- Re: AC_TRY_COMPILE() annoyances with 2.63b, Mike Frysinger, 2009/04/06
- Re: AC_TRY_COMPILE() annoyances with 2.63b,
Eric Blake <=
- Re: AC_TRY_COMPILE() annoyances with 2.63b, Ralf Wildenhues, 2009/04/07
- Re: AC_TRY_COMPILE() annoyances with 2.63b, Ralf Wildenhues, 2009/04/07
- Re: AC_TRY_COMPILE() annoyances with 2.63b, Mike Frysinger, 2009/04/07
- Re: AC_TRY_COMPILE() annoyances with 2.63b, Andreas Schwab, 2009/04/07
- AS_IF optimization (was: AC_TRY_COMPILE() annoyances with 2.63b), Eric Blake, 2009/04/07
- Re: AS_IF optimization (was: AC_TRY_COMPILE() annoyances with 2.63b), Andreas Schwab, 2009/04/07
- Re: AS_IF optimization, Eric Blake, 2009/04/07
- Re: AS_IF optimization, Eric Blake, 2009/04/10
- Re: AC_TRY_COMPILE() annoyances with 2.63b, Eric Blake, 2009/04/10