How do I prevent a quoted include from searching t

gcc provides the -I- option, for which -I directories preceding the -I- are searched for quoted includes (#include "foo.h"), and -I directories following the -I- are searched for bracketed includes (#include <foo.h>), as well as after the others for quoted includes.

-I- has another very important effect. It removes the directory of the source file that the #include is in from the default search path. Normally a quoted include always searches the directory of the source file, and searches it before any -I or other directories. -I- therefore allows you to specify exactly where to go for quoted include files in the order you want, by removing that default path that otherwise would take priority.

So it sounds like I answered my question, yes? No. When I use -I- now, I get this nastygram:

cc1: note: obsolete option -I- used, please use -iquote instead

The problem is that -iquote does not remove the current directory from the search path. It is still always searched first, no matter what I provide to -iquote.

So the question is: how do I get the same effect as -I-, without using -I-, which has been deprecated and will eventually go away?

Elaboration:

Suppose files are laid out as follows:

srcdir/
    configure
    file1.c
    file2.c
    config.h

builddir/
    Makefile
    file1.o
    file2.o
    config.h
    libpudding.a

For various reasons, we can't remove config.h from srcdir (it will impact the build process on other platforms). However, we want to include the config.h from builddir in preference to the zconf.h in srcdir.

This can be accomplished with GCC's -I- flag, but it seems otherwise impossible.

Updated question:

Ok, it seems like the GNU CC developers deprecated -I-, but did not provide an alternative way to achieve its functionality. So my updated question is: what is the most effective way to bring this to the attention of the developers so that there is a high probability that either -I- is undeprecated (which I would find most preferable, since it is a quite elegant way to handle specifying the search, much more so and much less ugly than -iquotexxx), or that some way is provided to remove the current directory from a quoted include search path?

Having worked with annoyances of zconf.h in an out-of-tree build, I would definitely go back to your point that when a question is super-tricky, it's often the wrong question. You're absolutely right. The right question is why zconf.h exists in srcdir at all, when it should be generated from zconf.h.in. A file should either be always generated or never generated for a given set of configuration settings. It should never be both provided and generated in the same build.

The best solution here is to remove zconf.h from the source tree and always generate it from zconf.h.in just as you do in the CMake build. I've never been clear why its done one way for CMake and another for Make. If the point is that you don't have autoconf, and so you're going to use a pre-built zconf.h for make, but a CMake-generated one for CMake, then just ship it as zconf.h.in (which you do), and copy it into the build tree in the Makefile.

Getting rid of the bizarre behavior of -I- was a good move. Having multiple files in your search path which are referred to with the same name is extremely confusing and ugly. If the -I search order matters, then something is not designed correctly in your project or in your build. I should never have to guess what #include "foo.h" refers to. I should definitely never be in a situation where it is easy to find yourself editing the wrong file.

I applaud your work improving the zlib build. zlib is certainly not the hardest package to build, but it is certainly not the easiest either (particularly if you need the contrib/minizip stuff, which I invariably do).