PCH, really relocatable

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

PCH, really relocatable

Axel Naumann
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@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.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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@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
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev