As automake generates, the usual way to create
automatic dependencies is by adding something like
-MD -MP -MT a.o -MF a.deps
to the normal compilation line, giving the benefit
of gcc's one-pass compile + make depend.
If we use PCH, one might need a compilation like:
g++ -include pch.h -c a.cc
and thus end up with doing:
g++ -include pch.h -c a.cc -MD -MP -MT a.o -MF a.deps
Often, the PCH (pch.h in this case) contains a LOT of header files,
and we don't want to recompile every compilation unit when we
touch a single header, even when all source files are including
this pch.h. So, correctly, the dependency tracking is ignoring both
pch.h and whatever it includes.
The real dependency information is therefore gathered from
the #include's inside a.cc. And here is the problem, when a.cc
does include "a.h", then this is recorded - but when a.h uses the
usual inclusion gard macros, and it is including "a2.h", then we
don't see that back in the output to a.deps! After all, the pre-
processor thinks that gard macro of a.h is defined (which is the
case because a.h was included before from pch.h) and there does
not process the #include's in a.h for the same of dependency
I've included a simple test case that demonstrates this.
Please untar and execute the commands:
The output will be:
a.o: a.cc a.h
Compare this with:
g++-cvs-3.4 -c a.cc -MD -MP -MT a.o -MF a.deps
g++-cvs-3.4 -c b.cc -MD -MP -MT b.o -MF b.deps
a.o: a.cc a.h a2.h
Created attachment 5781 [details]
Confirmed, related to bug 14933.
This is correct behaviour. When the PCH is in use, a2.h is not directly used in the compilation of a.o.
You could delete a2.h and the compilation would still succeed.
It is not correct behaviour.
If you delete a2.h then the PCH file SHOULD be made
(it depends on a2.h) and would fail. Deleting it is
no different than changing it. When you change it,
then you want both, the PCH file to be remade as well
as all compilation units depending on a2.h (not pch.h).
> It is not correct behaviour.
> If you delete a2.h then the PCH file SHOULD be made
> (it depends on a2.h) and would fail. Deleting it is
> no different than changing it. When you change it,
> then you want both, the PCH file to be remade as well
> as all compilation units depending on a2.h (not pch.h).
Right, but a.o does not directly depend on a2.h. a.o depends on pch.h.gch which depends on a2.h.
It sounds like what you want is the answer to the question "if the -include was not passed, what would
the dependencies of a.o be?" You can get that answer by asking that question: by using
g++-cvs-3.4 -E a.cc -MD -MP -MT a.o -MF a.deps -o /dev/null
Alternatively, you might be wanting the answer to the question "if PCH was not used, what would the
dependencies of a.o be?" You can get the answer to that question by using the -fpch-deps flag.
Bug 14933 already covers the problem that pch.h.gch is not mentioned in the dependency list of a.o.