Re: HAVE_STDBOOL_H, AC_HEADER_STDBOOL, and AM_STDBOOL_H

[Eric Blake]

[re-adding autoconf; I'm not sure why you dropped it earlier]

On 02/01/2011 08:00 AM, Ralf Corsepius wrote:
>> The gnulib stdbool module is LGPLv2+, which is about as flexible as you
>> can be.  Using gnulib's stdbool replacement does NOT require an
>> application to become GPL.
>>
> At the price of pulling in another "el-weirdo" tool, where formerly no
> tool was necessary - Great progress!

To recap this thread:

AC_HEADER_STDBOOL substitutes a variable if the implementation's
<stdbool.h> is compliant.  This behavior will not change (whether or not
we decide to mark the macro obsolete).  Applications can continue to
rely on this behavior and this variable if they are not using gnulib.

Setting the variable was useless for gnulib, since it also provides a
replacement <stdbool.h> that works on C89, therefore, no gnulib client
ever needs to probe HAVE_STDBOOL_H, but can just proceed to use
<stdbool.h>.  Use of gnulib's macro is worthless without also using
gnulib's replacement, at which point, you're better off using gnulib
than trying to duplicate gnulib's macro (but not replacement) into autoconf.

However, since the purpose of the macro differs between the two projects
(autoconf to set HAVE_STDBOOL_H, gnulib to provide replacement header),
this is a strong argument that gnulib should use a different macro name.
 It also implies that there might be portability issues checked by one
version of the macro but not by another.

If you care about using <stdbool.h> everywhere, even on C89, with the
few caveats that gnulib's replacement entails, then use gnulib's
approach.  If you only want to use <stdbool.h> when it is perfectly C99
compliant, but don't care about replacing it on systems with only C89 or
with a broken C99 implementation, then use autoconf's approach.

Given that we have just argued that there should be two separate macros,
although they are both based on similar tests, the problem of dual
maintenance is raised - if in the future we find some tweak of an
additional test that the macro must perform to filter out a broken
<stdbool.h>, should that tweak go in gnulib, in autoconf, or in both
projects?  The point of marking AC_HEADER_STDBOOL obsolete in autoconf
would be a conscious maintenance decision that says that we don't want
the dual burden, and that if a user wants the latest-and-greatest check
for a compliant header, then they should also look at gnulib's version.

Conversely, we've pretty much identified all the portability gotchas for
what makes a compliant <stdbool.h>, and it's unlikely that either
version of the macro will need much tweaking in the future.  So that
argues there's no maintenance burden even by splitting the macro, and
that marking the autoconf version of the macro as obsolete may end up
doing nothing more than draw out whines from the audience.

I agree 100% that the two macros must be split and that gnulib should
not use AC_HEADER_STDBOOL, but I don't (yet) see any convincing reason
either for or against marking the autoconf macro obsolete, since I just
argued that the end result is pretty much the same (either the autoconf
version won't be changed when the gnulib version is, because of the dual
maintenance burden; or the autoconf version won't be changed because
there are no further compliance tests to be written).  Therefore, the
argument of laziness says that for now, I won't be marking
AC_HEADER_STDBOOL as obsolete (I've already spent too long writing this
email).

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature