Re: proposed gnulib-related additions to Autoconf

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Paul Eggert on 2/28/2006 5:48 PM:
> Several macros in Gnulib really belong in Autoconf.  I took a first
> cut at migrating the code, and came up with the following proposed
> patch to Autoconf.  Not all the gnulib macros made the cut, and some
> needed to be renamed to avoid backwards-compatibility issues and to
> keep the naming conventions.  Comments welcome.

Looks good to me!  I was hard-pressed to spot any obvious errors.  And it
is definitely a move in the right direction.

> 
> Part of the goal here, by the way, is for gnulib to not need any
> changes.  I haven't tested this yet (in fact, I haven't tested this
> change nearly enough for me to check it in yet to Autoconf).  I just
> wanted to put out a trial balloon for now.

For now, I haven't checked that either.

> Index: NEWS
...
> +
> +** AC_HEADER_ASSERT
> +  New macro that lets builder disable assertions.

I wonder if adding 'at configure time' at the end of that sentence would help.

> +
> +** AC_TYPE_INT8_T, AC_TYPE_INT16_T, AC_TYPE_INT32_T, AC_TYPE_INT64_T,
> +   AC_TYPE_INTMAX_T, AC_TYPE_INTPTR_T, AC_TYPE_LONG_LONG_INT,
> +   AC_TYPE_UINT8_T, AC_TYPE_UINT16_T, AC_TYPE_UINT32_T, AC_TYPE_UINT64_T,
> +   AC_TYPE_UINTMAX_T, AC_TYPE_UINTPTR_T, AC_TYPE_UNSIGNED_LONG_LONG_INT
> +  New macros to check for C99 types.
> +
> +** AC_C_TYPE_RANGE_INTEGER
> +  New macro to check for the lower and upper bounds of C integer types.
> +
> +** AC_TYPE_RANGE_INT8_T, AC_TYPE_RANGE_INT16_T, AC_TYPE_RANGE_INT32_T,
> +   AC_TYPE_RANGE_INT64_T, AC_TYPE_RANGE_INTMAX_T, AC_TYPE_RANGE_INTPTR_T,
> +   AC_TYPE_RANGE_LONG_LONG_INT, AC_TYPE_RANGE_PTRDIFF_T, 
> AC_TYPE_RANGE_SIZE_T,
> +   AC_TYPE_RANGE_UINT8_T, AC_TYPE_RANGE_UINT16_T, AC_TYPE_RANGE_UINT32_T,
> +   AC_TYPE_RANGE_UINT64_T, AC_TYPE_RANGE_UINTMAX_T, AC_TYPE_RANGE_UINTPTR_T,
> +   AC_TYPE_RANGE_UNSIGNED_LONG_LONG_INT
> +  New macros to check for the lower and upper bounds of C99 types.

Should we also provide a collector macro that ensures that all C99 types
and bounds are available, rather than having the user list so many macros
in their configure.ac?  Something like AC_TYPE_C99_TYPES might be a
reasonable name.

> Index: doc/autoconf.texi
...
>  
> address@hidden AC_STRUCT_DIRENT_D_INO
> address@hidden
> address@hidden HAVE_STRUCT_DIRENT_D_INO
> +Perform all the actions of @code{AC_HEADER_DIRENT} (@pxref{Particular
> +Headers}).  Then, if @code{struct dirent} contains a @code{d_ino}
> +member, define @code{HAVE_STRUCT_DIRENT_D_INO}.
> address@hidden defmac

Should we also document that a d_ino of 0 on older platforms implies a
deleted file, at which point [l]stat() is necessary to check for
existance?  Is it worth special-casing this macro to detect older versions
of cygwin?  In cygwin 1.5.18 and earlier, a d_ino member was present but
often contained random data instead of an inode.  Cygwin 1.5.19 got rid of
it altogether, although a patch is under testing for the eventual 1.5.20
to add a d_ino that always matches the actual st_ino.  My personal
inclination here is that since the cygwin community always recommends
upgrading to the latest version, it is okay if we don't special-case
cygwin in AC_STRUCT_DIRENT_D_INO.

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEBao284KuGfSFAYARAmCdAJ4lwDp8Nvw5QVEoql7XrQXzsSEP1wCaA8V4
wU8blI/2Lus7GiPIi0drmwg=
=VbR4
-----END PGP SIGNATURE-----