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". > 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). 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. 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. Paolo
