gcc provides the -I-
option, for which -I
directories preceding the -I-
are searched for quoted includes (#include \"foo.h\"
)
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).