I finally got around to do some testing with real-world software.
So far, I haven't seen any major problems, but there are a few
little things I'd like to have explained, as I didn't follow the
discussions here too closely.
Consider the following configure.in fragment. It checks whether the
sig_atomic_t type is defined in signal.h, and whether it's declared
volatile:
AC_MSG_CHECKING(for sig_atomic_t in signal.h)
AC_EGREP_HEADER(sig_atomic_t,signal.h,
[
ac_cv_type_sig_atomic_t=yes;
AC_EGREP_HEADER(volatile.*sig_atomic_t,
signal.h,
[
is_sig_atomic_t_volatile=yes;
AC_MSG_RESULT([yes, volatile])
],
[
is_sig_atomic_t_volatile=no;
AC_MSG_RESULT([yes, non volatile])
])
],
[
AC_MSG_RESULT(no)
AC_CHECK_TYPE(sig_atomic_t, int)
is_sig_atomic_t_volatile=no
])
An autoconf 2.13 generated configure script generates the following output:
checking for sig_atomic_t in signal.h... yes, non volatile
An autoconf 2.49e (today's cvs) creates this output:
checking for sig_atomic_t in signal.h... checking for stdlib.h... yes
checking for string.h... (cached) yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for unistd.h... yes
yes, non volatile
I'd like to know why autoconf inserts this "virtual" AC_CHECK_HEADERS
code.
