Discussion:
What is AC_CHECK_FUNCS_ONCE?
Bruno Haible
2003-04-22 18:47:20 UTC
Permalink
Hi Akim,

In http://mail.gnu.org/archive/html/bison-patches/2003-03/msg00057.html
I would like to warn the authors of this _ONCE stuff.
That's me. Thanks for the warning :-)
some macro named AC_CHECK_FUNCS_ONCE which is not an Autoconf macro,
and therefore should not be named AC_.
You know better than me how to realize this macro in Autoconf. Can you
put AC_CHECK_FUNCS_ONCE into autoconf, or - even better - make
AC_CHECK_FUNCS behave like it by default?

The raison d'ĂȘtre of this macro is that we have 8 modules in gnulib
which each need AC_CHECK_FUNCS(isascii), and similarly for other
functions, headers, and declarations. Without any countermeasure a
package which invokes these autoconf macros will:

1) have an unnecessarily large configure file. Remember, ca. 1 KB
for each AC_CHECK_FUNCS invocation. This bloats up every GNU
package in the long run.

2) cause the user/installer to wonder when he sees:

$ ./configure
...
checking for isascii... yes
...
checking for isascii... (cached) yes
...
checking for isascii... (cached) yes
...
checking for isascii... (cached) yes
...
checking for isascii... (cached) yes
...
checking for isascii... (cached) yes
...
checking for isascii... (cached) yes
...
checking for isascii... (cached) yes
...

My thoughts when I see this from a single configure file (not even
from different configure files in subdirectories!) is that it
must be insane underneath.

AC_CHECK_FUNCS_ONCE is an answer to 1). You could fix 2) by just
omitting the message if the value is in the cache.
@example
checking for sprintf... no
@end example
@noindent
What happened is that Autoconf knows that checking for a function
requires a compiler for the current language (here, C), so it actually
@example
AC_INIT
AC_ARG_WITH([fprintf])
if test "x$with_fprintf" = xyes; then
AC_PROG_CC
AC_CHECK_FUNCS(fprintf)
fi
AC_ARG_WITH([sprintf])
if test "x$with_sprintf" = xyes; then
AC_CHECK_FUNCS(sprintf)
fi
@end example
This is a bug in autoconf, because

1) You haven't documented which AC_* macros are callable inside
'if' and which are not? (Some certainly are, like AC_DEFINE,
right?)

2) Why should a configure file test for 'fprintf' when it doesn't
need the result? Or in the case of error.m4:

AC_FUNC_ERROR_AT_LINE
dnl Note: AC_FUNC_ERROR_AT_LINE does AC_LIBSOURCES([error.h, error.c]).
- if test $ac_cv_lib_error_at_line = no; then
- jm_PREREQ_ERROR
- fi
+ jm_PREREQ_ERROR
])

Why should the configuration spend time to check the prerequisites
of a file that will not be compiled on the particular platform?
Gimme a real reason, other than "autoconf currently doesn't work
that way".

Bruno
Akim Demaille
2003-04-25 17:31:16 UTC
Permalink
Bruno> Hi Akim,

Hi Bruno,

I'm very sorry for my miserable responsiveness. I have to face too
many duties, and I'm afraid I'm not very useful to the free software
currently :(
some macro named AC_CHECK_FUNCS_ONCE which is not an Autoconf macro,
and therefore should not be named AC_.
Bruno> You know better than me how to realize this macro in Autoconf. Can you
Bruno> put AC_CHECK_FUNCS_ONCE into autoconf, or - even better - make
Bruno> AC_CHECK_FUNCS behave like it by default?

Actually, I have this in mind since my first day in Autoconf, plus
some additional feature: I want

AC_CHECK_FUNCS(fnmatch)

to use the fnmatch specific code.

Bruno> The raison d'ĂȘtre of this macro is that we have 8 modules in gnulib
Bruno> which each need AC_CHECK_FUNCS(isascii), and similarly for other
Bruno> functions, headers, and declarations. Without any countermeasure a
Bruno> package which invokes these autoconf macros will:

I understand this very well! But it does require some surgery to
Autoconf, and extra care. I had a running proof of concept years ago,
but never had time to really make it into the real Autoconf.

If you read the following, you will certainly also understand why
there are more m4 loops than sh loops in recent macros. But note that
nothing prevents introducing sh loop for non specialized entities.
But again, this requires that someone takes some time to dive into
Autoconf's guts.

http://sources.redhat.com/ml/autoconf/1999-06/msg00071.html
http://sources.redhat.com/ml/autoconf/2001-04/msg00277.html
[...]
Bruno> This is a bug in autoconf, because

Bruno> 1) You haven't documented which AC_* macros are callable inside
Bruno> 'if' and which are not? (Some certainly are, like AC_DEFINE,
Bruno> right?)

Bruno> 2) Why should a configure file test for 'fprintf' when it doesn't
Bruno> need the result? Or in the case of error.m4:

Bruno> AC_FUNC_ERROR_AT_LINE
Bruno> dnl Note: AC_FUNC_ERROR_AT_LINE does AC_LIBSOURCES([error.h, error.c]).
Bruno> - if test $ac_cv_lib_error_at_line = no; then
Bruno> - jm_PREREQ_ERROR
Bruno> - fi
Bruno> + jm_PREREQ_ERROR
Bruno> ])

Bruno> Why should the configuration spend time to check the prerequisites
Bruno> of a file that will not be compiled on the particular platform?
Bruno> Gimme a real reason, other than "autoconf currently doesn't work
Bruno> that way".

"I don't know how to make it different, be my guest."

Loading...