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

On 11/02/2016 06:41 PM, Paolo Bonzini wrote:
> 
> 
> On 02/11/2016 23:14, Eric Blake wrote:
>> Our use of AC_REQUIRE hoists the check outside of any AS_IF or similar
>> code.  However, while I don't think any well-written configure.ac script
>> will be checking $ac_cv_func_foo prior to calling
>> AC_CHECK_FUNC_ONCE(foo), I _am_ a bit worried that poorly written
>> scripts that do:
>>
>> if condition
>>   AC_CHECK_FUNC_ONCE(foo)
>> fi
>> test $ac_cv_func_foo
> 
> I'm not worried about this.  However, now that I think more about it,
> I'm a bit more worried about something that has a deep chain of
> AC_REQUIREs, and ultimately ends up expanding AC_CHECK_FUNC_ONCE inside
> an "if".

Hmm. Yeah, I've been thinking over this all afternoon.  The old
_AC_FUNCS_EXPANSION expands once, but at the site of the first
AC_CHECK_FUNC_ONCE() [well, hoisted above AS_IF thanks to AC_REQUIRE],
regardless of what other context might be.

> 
>> Potential solution: collect the list of AC_CHECK_FUNC_ONCE functions in
>> an m4 list, and unroll that list where we used to do the AS_FOR, so that
>> we aren't changing the semantics of hoisting all the checks up front
>> early during configure.
> 
> 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).

m4_wrap lets us collect the list as we go, then expand code at the end.
But you're right - I have to expand it to some diversion, and creating a
diversion at the place where AC_CHECK_FUNC_ONCE() is first called isn't
likely to be useful.

> 
> Perhaps you can put the whole code for the tests in a variable (it's
> just a couple lines of shell if you add ac_fn_simple_define) in
> INIT_PREPARE or SHELL_FN, and then eval it in _AC_FUNCS_EXPANSION.

Or use diversions to craft a function header in SHELL_FN+N, body in
SHELL_FN+N+1, and tail in SHELL_FN+N+2, then have the site where
_AC_FUNCS_EXPANSION does its one-time expansion just call the shell
function.  Each body of the shell function would be a one or two line
check for the next C function being probed.  No need for an eval of a
huge shell string.  Oh, and you're right that N would have to be a
per-language offset.

Or maybe we can take a different approach.  Instead of eval, we can use
the knowledge that my proposal for a one-liner function still ensures
that we have a literal function name, literal cache variable name, and
literal witness name.  Instead of making ac_func_list be a list of
singletons 'func1 func2', it can be a list of triplets 'func1 cv1
witness1 func2 cv2 witness2' where our loop for processing them is no
longer a simple AS_FOR.  [Too bad we don't have python's ability to
easily suck off a tuple at a time from a list, but it can be emulated
easily enough].

> 
> That said, what I'm doing now is actually already done by
> AC_CHECK_DECLS_ONCE, so we might just document it as a possible
> incompatibility.

Indeed, that's my fallback approach if I don't come up with an elegant
solution in the next 24 hours.  It's unlikely to affect many real users,
and if it DOES affect someone, it will be a very obscure thing to track
down, but a mention in NEWS (and maybe a slight tweak to the
documentation wording to not promise up-front evaluation) should help if
we end up having to debug a real package that breaks as a result.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCAAGBQJYGpKsAAoJEKeha0olJ0NqRVUH/AvmYAFHX50aFqLCbo/lqZ6Q
DOCuy+6vMTDudKa10UGnlMIwBEVy2h0JSQnFCAm0i0XgxA5DtkDKGsJH8m5QPTm6
n5a4iv7gUH6CaOFavF+UvXAUSSOq5G+4vJH/H1I5Cm9F6dwRXOkhTMzSqDmuoMYB
fz8uQY8ecMshyPDj8HLwlAkArXoZRln3fNnn6i1pJ2hVpJB0o2GSB84ijcLolzqj
YfU/4NU7kfQd1uFtopNzhj7BFSUyMUEis1LTgwoJzJ6U4dc0v4i1qABaTjB6j0Qg
jF/gs9kXRyhPHFvRpyNjJaB60sEjK3CrfLvLCW3/rRY5AUWn+b42954i6i0t5TI=
=VlYu
-----END PGP SIGNATURE-----