[cfe-dev] PCH, really relocatable

Axel Naumann Axel.Naumann at cern.ch
Thu Jan 13 00:53:01 PST 2011


Hi,

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?

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.

What does the world want?

Cheers, Axel.



More information about the cfe-dev mailing list