[PATCH] 'yes' within the path sets wrong config variables

[Mike Frysinger]

On 03 Mar 2015 14:52, Benjamin Esquivel wrote:
> It seems that the 'AC_EGREP_CPP(yes...' example is quite popular
> but being such a short word to grep it is likely to produce
> false-positive matches with the path it is configured into.

change looks fine (except you need ChangeLog entries), but i wonder if this 
idiom is even the right one.  why aren't these all compile tests that do the 
standard "choke me" failure instead ?

autoconf-archive even has an off the shelf macro we could import:
ax_check_define.m4:AC_CHECK_DEFINE

then the code would be cleaner/easier to read:
	AC_CHECK_DEFINE([__AARCH64EB__], [
	  AC_DEFINE(HAVE_AARCH64_BE)
	  LIBC_CONFIG_VAR([default-abi], [lp64_be])
	], [
	  LIBC_CONFIG_VAR([default-abi], [lp64])
	])
this replaces all the code that is currently in sysdeps/aarch64/configure.ac.

it does mean the cache var changes names:
	libc_cv_aarch64_be -> ac_cv_defined___AARCH64EB__
but maybe we don't care ?  if that really is important to us, we could simply 
define our own macro based on that thatuses a different cache var name to our 
liking.

i haven't looked at the whole code base though to see whether this macro would 
be able to replace all of them ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20150303/a3037f26/attachment.sig>