This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug preprocessor/37292] New: -I- deprecated, but AFAIK no fully equivalent functionality is available
- From: "steve dot gcc at telxio dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 30 Aug 2008 23:35:05 -0000
- Subject: [Bug preprocessor/37292] New: -I- deprecated, but AFAIK no fully equivalent functionality is available
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
We build a large amount of software using a src tree and a separate object
tree.
We have recently upgraded from gcc v3.4 to gcc v4.3
$ gcc --version
gcc (GCC) 4.3.2
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
We are having a problem with include paths. The mechanisms for controlling the
algorithm used to select which header files are included has been deprecated
and the proposed replacement mechanism (-iquote) does not provide the same
functionality as the old mechanism (-I-). For example:
Using a representative build tree of:
src/
t.c
a.h
b.h
obj/
For the purposes of this example, t.c includes a.h and a.h subsequently
includes b.h.
$ cat ../src/t.c
#include "a.h"
$ cat ../src/a.h
#ifndef A_H
#define A_H
#include "b.h"
#endif
$ cat ../src/b.h
#ifndef B_H
#define B_H
#endif
In the obj directory, we build t.c:
$ gcc -c ../src/t.c -I. -I../src -H
. ../src/a.h
.. ../src/b.h
$
A problem with b.h is detected, it is fixed and a patch is created, this
results in a version of b.h in the obj/ directory (The patching mechanism is
part of the build process and is thus automated, the result is a patched
version of b.h is created as obj/b.h - this is the file that should be used,
not src/b.h).
Now we have:
src/
t.c
a.h
b.h
obj/
b.h (patched)
In the obj directory, we build t.c:
$ gcc -c ../src/t.c -I. -I- -I../src -H
cc1: note: obsolete option -I- used, please use -iquote instead
. ../src/a.h
.. ./b.h
$
The behaviour worked as required, but wanting to eliminate the warning and use
the recommended mechanism, I read the manual and found the description of
-iquote:
-iquotedir
Add the directory dir to the head of the list of directories to be searched
for header files only for the case of `#include "file"'; they are not searched
for `#include <file>', otherwise just like -I.
And changed my compile command to:
$ gcc -c ../src/t.c -iquote. -I../src -H
. ../src/a.h
.. ../src/b.h
Not what I wanted, so I tried all the other combinations of "-iquote.
-iquote../src" and "-I. -iquote../src" with the same result.
The manual is quite explicit that other than changing the order of search,
-iquote behaves just like -I, which means it is functioning as designed.
It appears the only way I can change the include search algorithm to achieve
the gcc v3.4 functionality is to use the '-I-' option which is now deprecated.
My fear of course is that it will go away in an upcoming release.
This is a documented feature in gcc versions prior to gcc 4, from the GNU CPP
(v3) man page:
-I- Split the include path. Any directories specified with
-I options before -I- are searched only for headers
requested with "#include "file""; they are not searched
for "#include <file>". If additional directories are
specified with -I options after the -I-, those
directories are searched for all #include directives.
In addition, -I- inhibits the use of the directory of
the current file directory as the first search directory
for "#include "file"".
Is there another supported option to achieve the functionality we are relying
on?
--
Summary: -I- deprecated, but AFAIK no fully equivalent
functionality is available
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steve dot gcc at telxio dot com
GCC build triplet: sparc-sun-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37292