Bug 19541

Actually I don't understand the problem, using a PCH directory file makes this work without any trouble 
really and without any thinking (and I already showed that it was documented).

mkdir src build
echo 'extern int foo;' > src/foo.h
echo >src/bar.c '#include "foo.h"
int bar(void) { return foo; }'
cd build
gcc -o foo.h.gch ../src/foo.h
gcc -H -c ../src/bar.c

This will not use the gch in the current directory,
unless I also specify `-I. -I-'.

Putting the pch under the source tree works against all VPATH build
principles (read-only source tree).  It does not matter whether I
use a directory build/foo.h.gch/ or a file.

(The other bug I reported was indeed false, apologies for the
reading disability that struck me there.)

This also happens with 3.4.4

Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01197.html

*** Bug 27137 has been marked as a duplicate of this bug. ***

(In reply to comment #4)
> Patch posted here:
> http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01197.html
> 

This patch would meet my needs if the -I- option is removed from gcc.  Without it
or the -I- option, I would have to find a new compiler to work with my codebase
(it makes extensive use of VPATHs similar to the nmake's viewpathing feature
and it would be impractical to edit all header file references to change them
from "" to <>).

*** Bug 34855 has been marked as a duplicate of this bug. ***

Changing component; the patch here doesn't touch the preprocessor at all.

(In reply to comment #8)
> Changing component; the patch here doesn't touch the preprocessor at all.
> 

If you are changing the component, would not a better choice be "driver" than "c"? 

I agree the patch does not touch the preprocessor code, but from a user point of view it is a preprocessor issue. The 4.2.2 manuals say in section 3.11 that "The preprocessor's direct interface is undocumented and subject to change, so whenever possible you should avoid using -Wp and let the driver handle the options instead." A user could reasonably (but wrongly) assume that the driver passes options like -I to the preprocessor.

If you are changing the component, then can you change the severity to something more suitable than "enhancment" at the same time? Whilst I am all in favour of emitting warnings about obsolete features, until there is a working replacement for -I- it is a bug to complain that it is deprecated.

An updated patch for gcc 4.3 is available in the following message:

http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00653.html

Please ping that patch on the gcc-patches list.
Thanks.

*** Bug 37291 has been marked as a duplicate of this bug. ***

*** Bug 37292 has been marked as a duplicate of this bug. ***

Please, could anyone increase priority and serverity of this bug?

The current documentation that pretends that -iquote could work as replacement is plain wrong. A proper replacement for -I- is needed. A solution has been proposed long ago. Fixes are around.

Of course, like other people (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34855#c5) my favourite solution would be if you could "undo the deprecation of -I-, as it is used by other compilers."

This is still a huge issue.  We would wish to inhibit use of the CURRENT Working directory to find include files.  Basically FORCE every time a new include file is found with #include to start AGAIN from the begining of the Include Path system.  using -iquote will simply cause the same problem where an include file that includes another include file will include that sub-include file even if you can pulled it away in a previous include path.

Make files with VPATH or put Development paths first in lists are totally hosed by removing the -I- functionality.  This is NOT an enhancement but a Priority 2 bug which there is NO WORKAROUND provided by removing a feature.  

So is this item a) still unresolved b) resolved but not verified/released c) never to be resolved ?

All versions since 4.0.0 seem to still have this issue.  We are still awaiting it, and its not assigned to anyone either.

So there is no hope for this option then ? Anybody have a work around... We
are considering drastic measures to work around this.

Thanks,
Chris


                                                                                                                                                 
  From:       "chris.litchfield at gmail dot com" <gcc-bugzilla@gcc.gnu.org>                                                                     
                                                                                                                                                 
  To:         Christopher Ferguson/Burlington/IBM@IBMUS                                                                                          
                                                                                                                                                 
  Date:       12/06/2010 03:14 PM                                                                                                                
                                                                                                                                                 
  Subject:    [Bug c/19541] need another option to support what -I- did just besides -iquote                                                     
                                                                                                                                                 





http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19541

--- Comment #17 from Chris Litchfield <chris.litchfield at gmail dot com>
2010-12-06 20:13:30 UTC ---
All versions since 4.0.0 seem to still have this issue.  We are still
awaiting
it, and its not assigned to anyone either.

--
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

For now, we keep the -iquote in and hope the other parts are not removed. In our shop we have many different functions to try and mitigate the problem.  Include files have #defines at the top to prevent the includes from being double included, use the proper syntax of #include <> and #include "" when appropriate. Hard coding the include path is just horrible for coding and deemed unacceptable for us. 

One of the workarounds is drastic but involves configuration management to the extreme.  All source files and include files in the same directory and to verify that NO include files are ever duplicated.  This can be done and use virtual designs for your "projects" in IDEs. 

Redesign of the Include files so they do not pull in other include files or have a layer of include files that include other files but when you change the sub-include files, it automatically pulls in the above layer include file.

Yes, all these are ugly for something that should be part of ANY include system. There is a reason an Include Path exists, and to use "shortcuts" as standard practice inside the compiler hurts everyone here complaining about it.  Quite a few developers just continue to use older compiler versions as no need to upgrade into some of the pain.

Wish we could assign this to someone. I bet we could keep the needed option as a separate option (-I-). Dont know what this was last reconfirmed 2006 though...

Chris

(In reply to comment #18)
> So there is no hope for this option then ? Anybody have a work around... We
> are considering drastic measures to work around this.
> 
> Thanks,
> Chris
> 
> 
> 
>   From:       "chris.litchfield at gmail dot com" <gcc-bugzilla@gcc.gnu.org>    
> 
>   To:         Christopher Ferguson/Burlington/IBM@IBMUS                         
> 
>   Date:       12/06/2010 03:14 PM                                               
> 
>   Subject:    [Bug c/19541] need another option to support what -I- did just
> besides -iquote                                                     
> 
> 
> 
> 
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19541
> 
> --- Comment #17 from Chris Litchfield <chris.litchfield at gmail dot com>
> 2010-12-06 20:13:30 UTC ---
> All versions since 4.0.0 seem to still have this issue.  We are still
> awaiting
> it, and its not assigned to anyone either.
> 
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.

*** Bug 47741 has been marked as a duplicate of this bug. ***

I want to add my voice to others who have asked that the priority of this bug be elevated to P2.

Eliminating the secondary function of -I- as quoted from the GNU preprocessor documentation is unacceptable.

"Second, the directory containing the current file is not searched for anything, unless it happens to be one of the directories named by an -I switch."

Even if a different switch is used, like the -ignore-source-dir I've heard some rumblings about, can this issue please be elevated in priority and addressed soon?

For our code base, we utilize gcc along with commercial cross-compilers. All of the cross-compilers we use support an option that implements the original -I- behavior and in order to maintain our existing code base, we either -I- to no longer be deprecated or replaced with a different option that implements the same behavior.

Created attachment 26553 [details]
Remove deprecation warning for -I- (gcc-4.6.2)

Patch against gcc-4.6.2 to remove the deprecation warning for -I- since there's no complete replacement for it yet.  This will probably ruffle some feathers; sorry about that.

FWIW, it's my intention to keep this patch updated (at http://achurch.org/patch-pile/#gcc) until either it's officially undeprecated or a replacement for the "ignore source directory" functionality of -I- is available.

How difficult is it to add a parameter to add paths to precompiled header search list *only*? 

We have a big code base with #include "pch.h" in some source files. 
If source file directory is always searched first for headers, this breaks out-of-source builds, unless the precompiled header is generated in the source tree. For read-only source trees, this "solution" is unacceptable.

The ideal solution would be a parameter like -ipch <path> that adds <path> to be searched for precompiled headers *before* the current source directory.

I could spend some time creating a patch, but seeing that others have come with patches that weren't applied, this kind of demotivate me.

I can confirm the bug is still present in GCC 4.8.2 and 4.9.1. It affects my workflow in the following way: I need to include stub header files instead of the original ones (which can reside in the same directory as the compiled source file) for the purpose of unit-testing. So I need GCC to consider some include directories before the current directory (which I provide as an include directory later anyway). The -I- option can do the job, -iquote absolutely not.

I found other affected users when searching for the solution on StackOverflow:
* http://stackoverflow.com/questions/12353429/prevent-gcc-from-searching-the-current-dir-i-option-on-include-search-path
* http://stackoverflow.com/questions/3162510/how-to-make-gcc-search-for-headers-in-a-directory-before-the-current-source-file

Please fix this issue by either undeprecating the -I- option or introducing the -ignore-source-dir option as proposed in https://gcc.gnu.org/ml/gcc-patches/2006-03/msg01197.html.

I also vote for preserving the -I- original behavior, i.e. simply get rid of the deprecation message from the precompiler. We also have situations where code is pulled in from other directories and vpath is in play, and these sort of use cases rely on the behavior provided by -I-, despite the original motivation behind wanting to deprecate it. Thanks.

After 11 years since the first report I can confirm the bug is still present in gcc-6:
 
 -the compiler still claims that -I- is deprecated,

 -it also still lies that -iquote can be used instead, 

 - and it still does not provide any other option to get rid of the current file's directory from the search path...

I've updated the undeprecation patch at http://achurch.org/patch-pile/#gcc for 4.9.4 and 6.2.0 (sorry about laziness).

I'm mildly amused at how the quotation style ('...' vs `...') and line wrap column in the pregenerated info files varies more or less randomly between versions.  It certainly makes updating the patch an interesting task...