home | list info | list archive | date index | thread index

[OCLUG-Tech] any thoughts on the deprecation of the "-I-" cpp search path option?

  • Subject: [OCLUG-Tech] any thoughts on the deprecation of the "-I-" cpp search path option?
  • From: "Robert P. J. Day" <rpjday [ at ] crashcourse [ dot ] ca>
  • Date: Sat, 28 May 2016 05:23:49 -0400 (EDT)
  i'm sure i asked about this once, but i'm curious if anyone on this
list is immersed in gcc/compiler issues enough to be following the
progress of the deprecation of the cpp "-I-" option.

  from the current man page for cpp:

  -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"".

      This option has been deprecated.

it's that second paragraph that, AFAICT, made that option always a bit
contentious -- that it would allow one to override the search path for
header files included with double quotes so that the current directory
would *not* be searched first, which strikes me as massively
non-intuitive.

  apparently, this would allow the use of header file "overlay"
directories, so that you could override even header files right there
in the current directory you were including with, you know:

  #include "rday.h"

there's an ongoing discussion of this here:

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

where people compare this with make's VPATH feature, and where it's
obvious that a lot of people have designed build environments that
take advantage of this option, and are unhappy about its deprecation.
they also point out that the advice from the GNU people is to use
"-iquote" instead, which most certainly does not give you equivalent
behaviour.

  so ... anyone on this list been following this, or in the position
of being directly affected by it?

rday

p.s. i'm particularly interested in the opinion that one should not
have designed a build environment that took advantage of that feature
in the first place, because it *is* so non-intuitive. here:

http://stackoverflow.com/questions/12353429/prevent-gcc-from-searching-the-current-dir-i-option-on-include-search-path

someone writes:

"Our dev environment makes heavy use of directories with locally
modified headers that should be seen by the compiler instead of the
"committed" "repository" versions."

  well, uh, isn't that exactly what a local working directory with
your local changes is supposed to do, a la Git? what "-I-" appears one
to do is allow *others* to override your local header files, which
strikes me as kind of a chaotic situation.

  perhaps there's a build environment design for which that makes
sense, but it strikes me as completely unpredictable if others are
allowed to make changes to header file override directories that will
affect *your* build.

  thoughts?

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================


message navigation