r241653 - Revert "Revert r241620 and follow-up commits" and move the initialization

[Manuel Klimek]

On Wed, Jul 8, 2015 at 6:10 PM Adrian Prantl <aprantl at apple.com> wrote:

>
> On Jul 8, 2015, at 9:03 AM, Manuel Klimek <klimek at google.com> wrote:
>
> On Wed, Jul 8, 2015 at 5:53 PM Adrian Prantl <aprantl at apple.com> wrote:
>
>> > On Jul 8, 2015, at 5:04 AM, Manuel Klimek <klimek at google.com> wrote:
>> >
>> > Daniel pointed out this introduces a new dependency onto codegen from
>> tools that only need to parse - was this somehow already there earlier?
>> What does this buy us? (I'm probably missing something :)
>> >
>>
>> For module debugging we want to emit debug info for the data types
>> defined by a clang module alongside the serialized clang ast when building
>> pch/pcm files. This way we can avoid emitting tons of redundant types in
>> the debug info of each object that was built against the module.
>>
>> A tool that wants to parse *and* make use of clang modules or precompiled
>> headers produced by clang will need to link against codegen. Tools that
>> don’t want/need clang modules, or can use a separate module cache can
>> continue to use the RawPCHContainerOperations without introducing any extra
>> dependency. This currently true for all of clang-tools-extra, for example.
>
>
> Thanks for explaining, that makes sense. Does debug info really need the
> full codegen library or only parts of it? (I have no idea how that part
> works ;)
>
>
> I could be possible to split out CGDebugInfo,
> ObjectFilePCHContainerOperations, and BackendUtil into a separate library
> but looking at the include list in CGDebugInfo it looks like that would
> also pull in CGBlocks, CGCXXABI, CGObjCRuntime, CodeGenFunction, and
> CodeGenModule and I think then there is not that much left.
> It’s not impossible to split off a data-types-only CGDebugInfo base class
> to get rid of most of these dependencies, but that’s a larger project.
>

Makes sense, thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150708/e829375e/attachment.html>