Re: more #include_next patches for iconv_open, netinet_in, sys_stat, etc.

[Bruno Haible]

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