This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: [Bug pch/13218] Potential problems with PCH and includes relative to current directory
- From: Geoff Keating <geoffk at geoffk dot org>
- To: Carlo Wood <carlo at alinoe dot com>
- Cc: gcc-bugs at gcc dot gnu dot org
- Date: 30 Nov 2003 22:52:19 -0800
- Subject: Re: [Bug pch/13218] Potential problems with PCH and includes relative to current directory
- References: <20031128171002.13218.carlo@gcc.gnu.org><20031130061212.12714.qmail@sources.redhat.com><20031130171039.GA10824@alinoe.com>
Your problem is that you're using '-I.', but '.' is not the same
directory when building and using the PCH. If you used '-I../b', or
better yet an absolute path, your problem would go away.
GCC's PCH is *not* a header cache. It does not check that you haven't
changed, moved, or deleted source files since you created the
PCH---whether through using emacs, changing the current directory,
using chroot(), moving the PCH to a completely different machine,
different -I paths, filesystem corruption, or whatever. It doesn't
check that 'foo.h.gch' is actually the precompiled version of 'foo.h'
(you can perfectly well do 'gcc bar.h -o foo.h.gch'); it doesn't even
check that there *is* a 'foo.h'. All these checks are the
responsibility of the build system---or, to be precise, if you want
these done then you should make the build system do them. (There are
many cases where you do *not* want them done.)
There is no suggestion anywhere in the documentation that GCC does
any checking of this kind. In fact, it specifically says:
> You will probably want to use a tool like @command{make} to keep the
> precompiled header up-to-date when the headers it contains change.
I don't think we should change the documentation to list all the
things that GCC doesn't do. It'd be a very long list.
I'm even a bit hesitant to give people more guidance about how to use
PCH than we do now, in the GCC manual. It seems like such advice
would be better somewhere else, like the automake manual. I suspect
that in the general case ('How should I use PCH in my project?'), all
answers are as likely to mislead as to help.
I admit that it would be more convenient if PCH could be used to
create a fully transparent header cache. However, PCH is really not
the best tool for that task; you can only include one PCH in a
compilation, it's designed for speed over convenience, it requires
significant build system and source code changes to use, and PCH files
are too big. Per Bothner's "compile server" project *is* intended to
do this, but it is as yet experimental, and by itself it won't be as
fast as PCH files.
--
- Geoffrey Keating <geoffk@geoffk.org>