Paul Eggert wrote: > This approach will require some minor rewrites, e.g. in string_.h we'd > replace this: > > #if @HAVE_INCLUDE_NEXT@ > # include_next <string.h> > #endif > > #ifndef _GL_STRING_H > #define _GL_STRING_H > > #if ! @HAVE_INCLUDE_NEXT@ > # include @ABSOLUTE_STRING_H@ > #endif > ... our fixes go here ... > #endif > > with this: > > #include_next <string.h> > > #ifndef _GL_STRING_H > #define _GL_STRING_H > ... our fixes go here ... > #endif > > but I don't see any downside to this (to be honest, though, I don't > recall why the code currently departs from the usual pattern for using > #include_next).
Putting the include_next outside the double-inclusion guard is needed on Tru64 with DEC C, because they have a /usr/include.dtk/string.h that #include_next <string.h>, which is intended to grab /usr/include/string.h but may grab our string.h replacement instead. Why not putting the include_next outside the double-inclusion guard always? Look at fcntl_.h, stdint_.h, wchar_.h, wctype_.h ... That said, in the particular case of string_.h, your proposed change is fine. > If the latter, I can generate a solution right away. What I'm leaning > towards is putting just this into the foo_.h file: > > #include_next <foo.h> > > and having the Makefile either leave this alone, or transforming it into > > #include "/path/to/system/foo.h" That sounds like some ununderstandable and fragile magic; I very much prefer the @...@ substitutions because it's immediately understandable what they do, from looking at the *_.h file. > This would simplify the source files, which is a good thing. But keeping the substitution mechanism simple is also a good thing, IMO. > It will > also make 'configure' run a bit faster, since when include_next works > 'configure' needn't compute the absolute file name of headers. This is an independent issue: You can already now bypass the call to gl_ABSOLUTE_HEADER when include_next works. This doesn't require making the Makefile.am rules more complex. Bruno
