User account creation filtered due to spam.

Bug 19541 - need another option to support what -I- did just besides -iquote
Summary: need another option to support what -I- did just besides -iquote
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: driver (show other bugs)
Version: 4.0.0
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL: http://gcc.gnu.org/ml/gcc-patches/200...
Keywords: patch
: 27137 34855 37291 37292 47741 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-01-20 08:12 UTC by Ralf Wildenhues
Modified: 2016-09-28 09:32 UTC (History)
18 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2011-02-14 20:19:18


Attachments
Remove deprecation warning for -I- (gcc-4.6.2) (1.87 KB, patch)
2012-02-02 13:38 UTC, Andrew Church
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ralf Wildenhues 2005-01-20 08:12:14 UTC
As noted in this thread:
http://gcc.gnu.org/ml/gcc/2005-01/msg01087.html
there is no way to make use of a precompiled header without
-I- in a VPATH build in case the header source and the C or
C++ source file including it reside in the same source directory.

Please consider adding a flag (-icwd?) to the preprocessor which will
cause the current directory to be search for pch before the source
directory.  Or consider to change the default pch search order.
Comment 1 Andrew Pinski 2005-01-20 15:29:48 UTC
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).
Comment 2 Ralf Wildenhues 2005-01-20 15:47:23 UTC
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.)
Comment 3 Rodolfo Schulz de Lima 2005-10-06 20:41:18 UTC
This also happens with 3.4.4
Comment 4 Andrew Pinski 2006-04-12 20:19:18 UTC
Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01197.html
Comment 5 Andrew Pinski 2006-04-13 16:45:18 UTC
*** Bug 27137 has been marked as a duplicate of this bug. ***
Comment 6 Peter Leven 2007-03-02 21:58:08 UTC
(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 <>).
Comment 7 Andrew Pinski 2008-01-18 19:51:35 UTC
*** Bug 34855 has been marked as a duplicate of this bug. ***
Comment 8 Tom Tromey 2008-01-18 21:52:53 UTC
Changing component; the patch here doesn't touch the preprocessor at all.
Comment 9 Icarus Sparry 2008-01-19 00:53:37 UTC
(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.

Comment 10 Daniel Villeneuve 2008-07-30 15:39:59 UTC
An updated patch for gcc 4.3 is available in the following message:

http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00653.html
Comment 11 Tom Tromey 2008-07-30 17:44:06 UTC
Please ping that patch on the gcc-patches list.
Thanks.
Comment 12 Andrew Pinski 2008-08-30 23:31:09 UTC
*** Bug 37291 has been marked as a duplicate of this bug. ***
Comment 13 Andrew Pinski 2008-08-30 23:37:57 UTC
*** Bug 37292 has been marked as a duplicate of this bug. ***
Comment 14 Johannes Schwenke 2009-01-14 12:18:55 UTC
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."
Comment 15 Chris Litchfield 2010-05-18 19:48:49 UTC
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.  
Comment 16 Chris Ferguson 2010-12-06 20:06:51 UTC
So is this item a) still unresolved b) resolved but not verified/released c) never to be resolved ?
Comment 17 Chris Litchfield 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.
Comment 18 Chris Ferguson 2010-12-08 15:59:03 UTC
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.
Comment 19 Chris Litchfield 2010-12-08 16:10:47 UTC
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.
Comment 20 Andrew Pinski 2011-02-14 22:54:02 UTC
*** Bug 47741 has been marked as a duplicate of this bug. ***
Comment 21 David Rosa 2011-06-28 14:14:37 UTC
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.
Comment 22 Andrew Church 2012-02-02 13:38:49 UTC
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.
Comment 23 Rodolfo Schulz de Lima 2013-06-16 14:52:36 UTC
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.
Comment 24 Miroslav Matějů 2015-07-16 09:21:33 UTC
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.
Comment 25 RGomes 2016-01-08 22:46:51 UTC
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.
Comment 26 Robert Luberda 2016-09-28 08:43:06 UTC
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...
Comment 27 Andrew Church 2016-09-28 09:32:31 UTC
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...