This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

Attachment: signature.asc
Description: Digital signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]