public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "carlo at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug preprocessor/14238] New: Dependency tracking and PCH Date: Sat, 21 Feb 2004 17:24:00 -0000 [thread overview] Message-ID: <20040221172413.14238.carlo@gcc.gnu.org> (raw) 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 tracking. I've included a simple test case that demonstrates this. Please untar and execute the commands: make depend-pch cat a.deps The output will be: a.o: a.cc a.h a.h: Compare this with: >make depend-nopch 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 >cat a.deps a.o: a.cc a.h a2.h a.h: a2.h: -- Summary: Dependency tracking and PCH Product: gcc Version: 3.5.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: carlo at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14238
next reply other threads:[~2004-02-21 17:24 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2004-02-21 17:24 carlo at gcc dot gnu dot org [this message] 2004-02-21 17:25 ` [Bug preprocessor/14238] " carlo at gcc dot gnu dot org 2004-04-13 4:27 ` [Bug pch/14238] " pinskia at gcc dot gnu dot org 2004-04-13 18:41 ` geoffk at gcc dot gnu dot org 2004-04-14 0:07 ` carlo at gcc dot gnu dot org 2004-04-14 8:04 ` geoffk at gcc dot gnu dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20040221172413.14238.carlo@gcc.gnu.org \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).