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 <kli...@google.com> wrote: > On Wed, Jul 8, 2015 at 6:10 PM Adrian Prantl <apra...@apple.com> wrote: > >> >> On Jul 8, 2015, at 9:03 AM, Manuel Klimek <kli...@google.com> wrote: >> >> On Wed, Jul 8, 2015 at 5:53 PM Adrian Prantl <apra...@apple.com> wrote: >> >>> > On Jul 8, 2015, at 5:04 AM, Manuel Klimek <kli...@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! >
_______________________________________________ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits