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

[Adrian Prantl]

> On Jul 8, 2015, at 9:29 AM, Daniel Jasper <djasper at google.com> wrote:
> 
> This still seems quite bad to me:
> 
> --- cfe/trunk/tools/clang-check/CMakeLists.txt (original)
> +++ cfe/trunk/tools/clang-check/CMakeLists.txt Tue Jul  7 20:00:30 2015
> @@ -1,8 +1,24 @@
> -set(LLVM_LINK_COMPONENTS
> +set( LLVM_LINK_COMPONENTS
> +  ${LLVM_TARGETS_TO_BUILD}
> +  Analysis
> +  CodeGen
> +  Core
> +  IPA
> +  IPO
> +  InstCombine
> +  Instrumentation
> +  MC
> +  MCParser
> +  ObjCARCOpts
>    Option
> +  ScalarOpts
>    Support
> +  TransformUtils
> +  Vectorize
>    )
> 

While typing up my previous I completely forgot that chapuni (thanks!) already went through the list of libraries in r241680 yesterday and removed all the unnecessary dependencies, leaving only the targets, Option and Support. Obviously, depending on the configuration, the targets will still be a considerable chunk, but in order to emit debug info when building modules we need the AsmPrinters.

-- adrian

> Have you look at how much this increases the binary size of clang-check, etc.?
> 
> On Wed, Jul 8, 2015 at 6:12 PM, Manuel Klimek <klimek at google.com <mailto:klimek at google.com>> wrote:
> On Wed, Jul 8, 2015 at 6:10 PM Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote:
> 
>> On Jul 8, 2015, at 9:03 AM, Manuel Klimek <klimek at google.com <mailto:klimek at google.com>> wrote:
>> 
>> On Wed, Jul 8, 2015 at 5:53 PM Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote:
>> > On Jul 8, 2015, at 5:04 AM, Manuel Klimek <klimek at google.com <mailto: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/5ec43e1f/attachment.html>