Created attachment 28326 [details] Some dummy sources demonstrating the issue Using GCC of Ubuntu Quantal, version gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1). Under some circumstances g++ does not find precompiled headers that are in the search path. I have attached a simple test case that demonstrates the issue. Just run compile.sh that comes with it and watch the output. In the test case there is a common.h header that includes a bunch of STL headers. It is in a subdirectory called hdir. The file is first precompiled and placed in the subdirectory pchdir. The script then compiles a bunch of files that include common.h but do very little else. Both pchdir and hdir are passed in with -I. The precompiled header is found and compilation is fast. Next the script copies common.h to the main directory and compiles the sources again using the exact same compiler switches. What happens is that g++ does not find the precompiled header, probably because it first looks in the source dir and finds common.h but not the corresponding pch and just stops looking. This makes the compilation very slow. Then the script copies the precompiled header to the main directory and compiles the files again. Now g++ finds the pch and compilation is again fast. Summing all this up: precompiled headers can not be used if the header is in the source directory and the pch is in some other directory which is included with -I. This is a problem when doing out-of-source builds.
(In reply to comment #0) > Next the script copies common.h to the main directory and compiles the sources > again using the exact same compiler switches. What happens is that g++ does not > find the precompiled header, probably because it first looks in the source dir > and finds common.h but not the corresponding pch and just stops looking. This > makes the compilation very slow. This is by design. A header included as #include "common.h" looks in the current dir first, so the compiler looks for ./common.h.gch, then for ./common.h, then stops because it's found. The alternative would be to continue searching *every* other directory looking for common.h.gch, which would be *much* slower (there might be no PCH anywhere, so for projects that don't use PCH it would mean checking every single directory for every single header) Maybe the solution you want is to use #include <common.h> and add -I. to the compilation commands, ensuring that -Ipchdir comes before -I. because that will not start with the current dir, and will look for pchdir/common.h.gch first and will stop when found. Doing that makes all three steps in your script very fast.
This sounds like the reason why some people want back -I- .
Thanks for the explanation and workaround. I guess this is not a big issue if you are using Autotools, where the established practice is to compile inside the source directory. It might cause a lot of head scratching for users of other build systems or those few autotools users that use a dedicated build directory.
I think the majority don't use PCH anyway.
> I guess this is not a big issue if you are using Autotools, where the > established practice is to compile inside the source directory. It is common practice to build outside the source directory, since it is very well supported.
Thus, not a bug then, no?