Re: how to handle architecture dependent headers in subdirectories
On Thu, Jan 17, 2013 at 01:21:41PM +0000, Ben Hutchings wrote:
> On Thu, 2013-01-17 at 12:06 +0000, Thorsten Glaser wrote:
> > Adam Borowski <kilobyte <at> angband.pl> writes:
> >
> > > #define DEB_HOST_MULTIARCH "x86_64-linux-gnu"
> >
> > And then #include "<" DEB_HOST_MULTIARCH "/foo/bar.h" or what?
> > Is that even valid C?
>
> It's not standard, nor is it supported in gcc (coincidentally I had a
> completely different reason to try it yesterday).
No, it is both blessed by ISO C, and supported by gcc:
6.10.2.2:
} # include <h-char-sequence> new-line
6.10.2.3:
} # include "q-char-sequence" new-line
6.10.2.4 says:
} A preprocessing directive of the form
} # include pp-tokens new-line
} (that does not match one of the two previous forms) is permitted. The
} preprocessing tokens after include in the directive are processed just as
} in normal text. (Each identifier currently defined as a macro name is
} replaced by its replacement list of preprocessing tokens.) The directive
} resulting after all replacements shall match one of the two previous
} forms. [...]
> > (#include CONFIG_H works in GCC, but…)
As required by the above.
> That *is* standard, but limited to a single macro.
You can combine them as you wish, there's just one trick: the #include line
_directly_ can include at most one of delimiters, or otherwise it will match
6.10.2.2 or 6.10.2.3 (yes, it is an unintuitive quirk). Also, the behaviour
of ## is unclear and might be what the following discussion declares to be
implementation specific, but fortunately, it's not needed:
#define STDIO stdio
#define _H .h
#define sysinclude(x) < x >
#include sysinclude(STDIO _H)
--
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ
Reply to: