[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 eblake@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
