[PATCH v3 3/4] AC_CHECK_FUNCS_ONCE: hoist cache name computation to m4 time

Rather than perform a sed script on each element of the $ac_func_c_list to compute the corresponding cache name, we can inline enough of AC_CHECK_FUNC to bypass the normal polymorphic code, and instead directly use the literal function name that we are consuming from the list. While at it, we can

[PATCH v3 0/4] limit number of cat and sed forks

Work in progress, because I still have to review patches 2 and 3 from Paolo's v2. (Patch 3 can probably be used as-is; patch 2 will probably necessitate the same changes to CHECK_DECLS_ONCE for honoring AC_LANG and reworking the shell list variable to hold tuples as I do here for

[PATCH v3 4/4] autoconf: prefer an unrolled loop for trivial AC_CHECK_FUNCS

From: Paolo Bonzini An unrolled loop avoids the cost of spawning sed in AS_TR_SH and AS_TR_CPP. Prefer it if there is nothing in the second and third argument of AC_CHECK_FUNCS and the first argument is a literal. * lib/autoconf/functions.m4 (AC_CHECK_FUNCS): Unroll loop if

[PATCH v3 1/4] AC_CHECK_FUNCS_ONCE: honor current AC_LANG

Previously, AC_CHECK_FUNCS_ONCE collected a list of function names to check, but ran the checks using the AC_LANG that was active during the first encounter of the macro. In practice, this is usually the C language, and we haven't had actual reports of projects attempting to use

[PATCH v3 2/4] AC_CHECK_FUNCS_ONCE: hoist CPP name computation to m4 time

Rather than perform a sed script on each element of the $ac_func_c_list to compute the corresponding CPP name, we can make the list store a series of pairs of function names and CPP names all computed at m4 time. The resulting configure script is slightly larger based on how many function names

Re: [PATCH v2 1/3] autoconf: prefer an unrolled loop for trivial AC_CHECK_FUNCS

On 11/02/2016 08:28 PM, Eric Blake wrote: >> How would you do that? You would have to expand before the first >> AC_CHECK_FUNC_ONCE, but you do not have a diversion there (you might >> need one per language, in fact). > > Oh, and you're right that N would have to be a > per-language offset.