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

Daniel Jasper djasper at google.com
Wed Jul 8 09:29:40 PDT 2015


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
   )

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> wrote:

> 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/cba9e528/attachment.html>


More information about the cfe-commits mailing list