[cfe-dev] PCH, really relocatable

[Douglas Gregor]

On Jan 13, 2011, at 12:53 AM, Axel Naumann wrote:
> we'd like to misuse PCHs as reflection databases, redistributed with our
> binaries. Users would add their own PCHs for their libraries. All of
> that in the context of a clang-based interpreter.
> 
> I didn't find a way to make the PCH work when the software got installed
> in a different directory. I.e. I'd like to have the PCH be insensitive
> to the location of its original headers. Sysroot won't help because
> different PCHs will require different sysroots and anyway it's (I
> believe) the wrong concept in this case.
> 
> I see two options (apart from me simply not finding the right flag :-),
> that are probably not even exclusive:
> 
> 1) The PCH is happy even if the original header files cannot be found.
> That would be the behavior that GCC exhibits:
> 
> $     g++ -x c++ -c t.h
> $ clang++ -x c++ -c t.h
> $ rm t.h
> $     g++ -include t.h -c t.cxx
> $ clang++ -include t.h -c t.cxx
> fatal error: malformed or corrupted PCH file: 'could not find file
> '/home/axel/t.h' referenced by AST file'
> 
> What's the reason for requiring the original headers to be around?

We need the headers around if we're dealing with source locations into that header, e.g., to compute line/column as part of displaying a diagnostic that refers into one of the precompiled headers. For example, but some function declaration in your PCH file:

	void foo(int);

and then use that PCH file in a translation unit that contains a conflicting declaration

	int foo(int);

and of course we need the sources of the headers in the PCH file around to display the note.

Now, we could delay the checking for missing/out-of-date headers until they're actually needed, and fail gracefully if the headers don't exist at that point. Much of this recovery code is already in Clang, so this shouldn't be terribly complicated.

> 2) Adding extended relocatability, where a PCH will be searched e.g. by
> an implicit, (lowest-priority?) -I, or an explicit -I at PCH@ of whatever.
> This would require that the -I used to find each header in the PCH is
> stored with the PCH, or that the header files' paths have that -I part
> removed: a file /home/axel/foo/bar/t.h found through -I./foo would need
> to be stored as bar/t.h.


This seems like a reasonable extension to the PCH mechanism.

	- Doug