[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proposed gnulib-related additions to Autoconf
From: |
Eric Blake |
Subject: |
Re: proposed gnulib-related additions to Autoconf |
Date: |
Wed, 01 Mar 2006 07:05:43 -0700 |
User-agent: |
Thunderbird 1.5 (Windows/20051201) |
-----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-----