Re: [PATCH 3/6] Modernize AC_INCLUDES_DEFAULT and friends.

[Eric Blake]

On 09/14/2013 10:22 AM, Zack Weinberg wrote:
>  * lib/autoconf/headers.m4 (_AC_INCLUDES_DEFAULT_REQUIREMENTS):
>    Include stddef.h, stdlib.h, and string.h unconditionally.
>    Don't include memory.h at all.
>    Don't use AC_HEADER_STDC.
>    Don't check for stddef.h, stdlib.h, string.h, or memory.h.
>    For compatibility, unconditionally define STDC_HEADERS,
>    HAVE_STDLIB_H, and HAVE_STRING_H.
>    (AN_HEADER list): Remove C89 headers, and memory.h from list.
>    (AC_HEADER_STDC, AC_UNISTD_H): AU_DEFUN to trigger
>    _AC_INCLUDES_DEFAULT_REQUIREMENTS if it hasn't already happened,
>    and do nothing else.

Good that you fix it up in 6/6.  As long as the whole series goes in, I
don't mind having the tree be temporarily in the odd state of listing an
internal macro in the user's file after autoupdating.

[after reading the whole patch]
Ah, I see what you did - you expanded to ac_dummy="AC_INCLUDES_DEFAULT"
rather than actually spelling out the internal macro name - it triggers
the internal macro via AC_REQUIRES magic.  Interesting :)

> +Using this macro without @var{include-directives} has the side effect of
> +checking for @file{sys/types.h}, @file{sys/stat.h}, @file{strings.h},
> address@hidden, @file{stdint.h}, and @file{unistd.h}, as if by
> address@hidden  For backward compatibility's sake, it also
> +unconditionally defines @code{HAVE_STRING_H}, @code{HAVE_STDLIB_H}, and
> address@hidden

Maybe add "; but it is safe for new code to be written without reference
to these three preprocessor macros."

> @@ -5744,6 +5761,29 @@ Posix Headers, gnulib, GNU gnulib} and @ref{Glibc 
> Header File
>  Substitutes, , Glibc Headers, gnulib, GNU gnulib}.  Please help us keep
>  the gnulib list as complete as possible.
>  
> +When we say that a header ``may require'' some set of other headers, we
> +mean that it may be necessary for you to manually include those other
> +headers first, or the contents of the first header will fail to compile.

Confusing double use of "first".  s/first header/header under test/

> +When checking for these headers, you must provide the
> +potentially-required headers in the @var{includes} argument to
> address@hidden or @code{AC_CHECK_HEADERS}, or the check will
> +fail spuriously.  @code{AC_INCLUDES_DEFAULT} (@pxref{Default Includes})
> +arranges to include a number of common requirements and should normally
> +come first in your @var{includes}.  For example, @file{net/if.h} may
> +require @file{sys/types.h}, @file{sys/socket.h}, or both, and
> address@hidden handles @file{sys/types.h} but not
> address@hidden/socket.h}, so you should check for it like this:
> +
> address@hidden
> +AC_CHECK_HEADERS([sys/socket.h])
> +AC_CHECK_HEADERS([net/if.h], [], [],
> +[AC_INCLUDES_DEFAULT
> +#ifdef HAVE_SYS_SOCKET_H
> +# include <sys/socket.h>
> +#endif
> +])

This might be a good place to demonstrate rules on single vs. double
quoted m4 arguments.  I would write the example like this, and include a
followup paragraph:

@example
AC_CHECK_HEADERS([sys/socket.h])
AC_CHECK_HEADERS([net/if.h], [], [],
[AC_INCLUDES_DEFAULT[
#ifdef HAVE_SYS_SOCKET_H
# include <sys/socket.h>
#endif
]])

Note that the example mixes single quoting (for
@code{AC_INCLUDES_DEFAULT}, so that it gets expanded) and double quoting
(to ensure that each preprocessor @code{#} gets treated as a literal
string rather than a comment).

> +
> +This header may or may not include @file{string.h} for you.  However, on
> +all recent systems it is safe to include both @file{string.h} and
> address@hidden in the same source file.

s/strings.h}/strings.h}, in either order, /

ACK with those changes.

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

signature.asc
Description: OpenPGP digital signature