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

[Paul Eggert]

Bruno Haible <address@hidden> writes:

> Yes, the IRIX 6.5 compiler gives a warning about #include_next, even inside
> #if 0:
>
> "foo.c", line 2: warning(1011): unrecognized preprocessing directive
>   #include_next <stdlib.h>
>    ^

Thanks for checking that.

> If we want to work around it, it's easy: have a substitution @INCLUDE_NEXT@
> that expands to #include_next or to empty...

That's easy, and I can do that, but I have a question first.  Are the
generated .h files intended to be useful by all compilers on a
platform, or just by the compiler and compiler options tested via
'configure'?  If the former, then we need a more-elaborate solution,
since 'configure' may find that #include_next works but the actual
compiler might not support #include_next.  (However, I suspect if the
former is true we have several other problems in this area.)

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"

This would simplify the source files, which is a good thing.  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 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).