[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: more #include_next patches for iconv_open, netinet_in, sys_stat, etc
From: |
Paul Eggert |
Subject: |
Re: more #include_next patches for iconv_open, netinet_in, sys_stat, etc. |
Date: |
Thu, 17 May 2007 12:32:01 -0700 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) |
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).
- more #include_next patches for iconv_open, netinet_in, sys_stat, etc., Paul Eggert, 2007/05/17
- Re: more #include_next patches for iconv_open, netinet_in, sys_stat, etc., Bruno Haible, 2007/05/17
- Re: more #include_next patches for iconv_open, netinet_in, sys_stat, etc., Eric Blake, 2007/05/17
- Re: more #include_next patches for iconv_open, netinet_in, sys_stat, etc., Paul Eggert, 2007/05/17
- Re: more #include_next patches for iconv_open, netinet_in, sys_stat, etc., Bruno Haible, 2007/05/17
- Re: more #include_next patches for iconv_open, netinet_in, sys_stat, etc.,
Paul Eggert <=
- Re: more #include_next patches for iconv_open, netinet_in, sys_stat, etc., Bruno Haible, 2007/05/17
- Re: more #include_next patches for iconv_open, netinet_in, sys_stat, etc., Bruno Haible, 2007/05/19
- Re: more #include_next patches for iconv_open, netinet_in, sys_stat, etc., Simon Josefsson, 2007/05/22
Re: more #include_next patches for iconv_open, netinet_in, sys_stat, etc., Eric Blake, 2007/05/17
Re: more #include_next patches for iconv_open, netinet_in, sys_stat, etc., Jim Meyering, 2007/05/17
Re: more #include_next patches for iconv_open, netinet_in, sys_stat, etc., Bruno Haible, 2007/05/29
- Prev by Date:
Re: more #include_next patches for iconv_open, netinet_in, sys_stat, etc.
- Next by Date:
Re: more #include_next patches for iconv_open, netinet_in, sys_stat, etc.
- Previous by thread:
Re: more #include_next patches for iconv_open, netinet_in, sys_stat, etc.
- Next by thread:
Re: more #include_next patches for iconv_open, netinet_in, sys_stat, etc.
- Index(es):