-I-: how is -iquote going to replace original functionality?

Wolfgang Wander wwc@rentec.com
Thu Apr 28 16:42:00 GMT 2005


Hi,

   with -I- now being deprecated, how is -iquote going to replace
its functionality?

I have the following test case with

./$ cat a.c
#include "a.h"
./$ cat a.h
#error dont include me
./$ cat a/a.h
int foo( int bar );


Now in the 'good-old-days' I could compile that code via:

./$ gcc -c -I- -Ia a.c

because -I- cleared the list of include directories for "" searches,
most importantly: including '.'

These days I try:


./$ gcc-4.0.0 -c -I- -Ia  a.c
cc1: note: obsolete option -I- used, please use -iquote instead

so I go

./$ gcc-4.0.0 -c -iquote -Ia a.c
In file included from a.c:1:
a.h:1:2: error: #error dont include me

That didn't work... What about:

./$ gcc-4.0.0 -c -iquote '' -Ia a.c
cc1: error: a.c: not a directory
... and now gcc reads from stdin, typing ^D brings it back

... other alternatives:

./$ gcc-4.0.0 -c -iquote a -Ia a.c
In file included from a.c:1:
a.h:1:2: error: #error dont include me

or

./$ gcc-4.0.0 -c -iquotedir a -Ia a.c
In file included from a.c:1:
a.h:1:2: error: #error dont include me

It sure seems that -iquote does not strip . from the "" search path.

--------------------------------------------------

This isn't purely academic - I know that I can change the 

  #include "a.h" 

to and

  #include <a.h>

to avoid this specific problem but I have to deal with vendor supplied
header files that use the "" notation unfortunately.

Did the deprecation of -I- in favour of -iquote omit the complete original
behaviour or is this a plot to force coders to stick to the C
standards? ;-)

              Wolfgang



More information about the Gcc-help mailing list