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] |
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] |