Mark D. Baushke wrote: > Paul Eggert <[EMAIL PROTECTED]> writes: > > > "Mark D. Baushke" <[EMAIL PROTECTED]> writes: > > > > > is it desirable to make those modules depend on stdint.m4 and avoid the > > > HAVE_STDINT_H macro? > > > > Yes, I think so, in the long run. But in the short run, stdint.m4 is > > not yet reliable enough (as you're finding out with SGI), and some > > packages don't want to rely on it for that reason. > > > > For cycle-check.h I'd think this wouldn't be a problem, since > > cycle-check.h uses this Autoconf-recommended sequence: > > > > # if HAVE_INTTYPES_H > > # include <inttypes.h> > > # endif > > # if HAVE_STDINT_H > > # include <stdint.h> > > # endif > > > > and this should work on SGI. > > With lots and lots of warnings, yes. > > The HAVE_STDINT_H is defined, even though it is useless
You are welcome to submit patches for ptrdiff_max.m4 and size_max.m4 and xsize.m4 so that they don't define HAVE_STDINT_H. > In CVS, the windows-NT does not supply a <stdint.h>, so we use stdint.m4 > to create one. However, the lib/*.c files do not build because there is > not one available when we tell the truth about HAVE_STDINT_H being > undef Several gnulib modules still use the classical #ifdef HAVE_STDINT_H # include <stdint.h> #endif pattern. Now we are testing the stdint complete module, 'libiconv' and 'cvs' being the guinea pigs. In a few months, we will get used to using <stdint.h> unconditionally like we now use <stdbool.h> without much thinking, and the various variants (ptrdiff_max.m4, size_max.m4, intmax_t.m4, uintmax_t) may disappear. Bruno
