Bruno Haible <[EMAIL PROTECTED]> 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).
