Bug 37291 - -I- deprecated, but AFAIK no fully equivalent functionality is available
Summary: -I- deprecated, but AFAIK no fully equivalent functionality is available
Status: RESOLVED DUPLICATE of bug 19541
Alias: None
Product: gcc
Classification: Unclassified
Component: preprocessor (show other bugs)
Version: 4.3.2
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-08-30 23:28 UTC by Steve Williams
Modified: 2008-08-30 23:31 UTC (History)
7 users (show)

See Also:
Host:
Target:
Build: sparc-sun-solaris2.10
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Steve Williams 2008-08-30 23:28:35 UTC
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?
Comment 1 Andrew Pinski 2008-08-30 23:31:09 UTC

*** This bug has been marked as a duplicate of 19541 ***