On Jul 24, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> What would be the problem with enabling the use of the fourth
> parameter of AC_CHECK_FUNCS? AC_CHECK_FUNC(func, yes, no, includes)?
IMO, it would be a step in the right direction, but it wouldn't
completely solve the problem. For one, autoconf currently doesn't
require functions to be prototyped for AC_CHECK_FUNC to succeed. Even
though C99 requires prototypes, older releases of the C Standard
don't, and we can't modify autoconf in a way that makes it unusable
for such environments. They're still going to stay around for a
while, for large values of while :-)
So I think the way to go may be to use the presence of [INCLUDES] for
two purposes: (i) to decide whether to include the standard headers or
not and (ii) to decide whether to retry the test with a fallback
declaration. We could then have an additional argument, in
AC_CHECK_FUNC, if not in AC_CHECK_FUNCS, that would provide fallback
declarations of functions whose declarations are missing.
Alternatively, INCLUDES could contain these declarations, properly
guarded by `#if defined HAVE_<func>_DECL && HAVE_<func>_DECL == 0', so
that they'd only apply in the second test, after AC_CHECK_FUNC has
already #defined HAVE_<func>_DECL to 0. As a side effect,
AC_CHECK_FUNC would now implicitly perform the AC_CHECK_DECL test for
functions.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me
