<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 8, 2015, at 9:29 AM, Daniel Jasper <<a href="mailto:djasper@google.com" class="">djasper@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">This still seems quite bad to me:<div class=""><br class=""></div><div class=""><span style="font-size:12.8000001907349px" class="">--- cfe/trunk/tools/clang-check/</span><span style="font-size:12.8000001907349px" class="">CMakeLists.txt (original)</span><br style="font-size:12.8000001907349px" class=""><span style="font-size:12.8000001907349px" class="">+++ cfe/trunk/tools/clang-check/</span><span style="font-size:12.8000001907349px" class="">CMakeLists.txt Tue Jul 7 20:00:30 2015</span><br style="font-size:12.8000001907349px" class=""><span style="font-size:12.8000001907349px" class="">@@ -1,8 +1,24 @@</span><br style="font-size:12.8000001907349px" class=""><span style="font-size:12.8000001907349px" class="">-set(LLVM_LINK_COMPONENTS</span><br style="font-size:12.8000001907349px" class=""><span style="font-size:12.8000001907349px" class="">+set( LLVM_LINK_COMPONENTS</span><br style="font-size:12.8000001907349px" class=""><span style="font-size:12.8000001907349px" class="">+ ${LLVM_TARGETS_TO_BUILD}</span><br style="font-size:12.8000001907349px" class=""><span style="font-size:12.8000001907349px" class="">+ Analysis</span><br style="font-size:12.8000001907349px" class=""><span style="font-size:12.8000001907349px" class="">+ CodeGen</span><br style="font-size:12.8000001907349px" class=""><span style="font-size:12.8000001907349px" class="">+ Core</span><br style="font-size:12.8000001907349px" class=""><span style="font-size:12.8000001907349px" class="">+ IPA</span><br style="font-size:12.8000001907349px" class=""><span style="font-size:12.8000001907349px" class="">+ IPO</span><br style="font-size:12.8000001907349px" class=""><span style="font-size:12.8000001907349px" class="">+ InstCombine</span><br style="font-size:12.8000001907349px" class=""><span style="font-size:12.8000001907349px" class="">+ Instrumentation</span><br style="font-size:12.8000001907349px" class=""><span style="font-size:12.8000001907349px" class="">+ MC</span><br style="font-size:12.8000001907349px" class=""><span style="font-size:12.8000001907349px" class="">+ MCParser</span><br style="font-size:12.8000001907349px" class=""><span style="font-size:12.8000001907349px" class="">+ ObjCARCOpts</span><br style="font-size:12.8000001907349px" class=""><span style="font-size:12.8000001907349px" class=""> Option</span><br style="font-size:12.8000001907349px" class=""><span style="font-size:12.8000001907349px" class="">+ ScalarOpts</span><br style="font-size:12.8000001907349px" class=""><span style="font-size:12.8000001907349px" class=""> Support</span><br style="font-size:12.8000001907349px" class=""><span style="font-size:12.8000001907349px" class="">+ TransformUtils</span><br style="font-size:12.8000001907349px" class=""><span style="font-size:12.8000001907349px" class="">+ Vectorize</span><br style="font-size:12.8000001907349px" class=""><span style="font-size:12.8000001907349px" class=""> )</span><br class=""></div><div class=""><span style="font-size:12.8000001907349px" class=""><br class=""></span></div><div class=""><span style="font-size:12.8000001907349px" class="">Have you look at how much this increases the binary size of clang-check, etc.?</span></div></div></div></blockquote><div><br class=""></div><div>At the moment this size increase affects only clang-check and c-index-test. An alternative that I considered was to force clang-check to use a different module cache than clang (and leave out the module object file container support), but that also means that clang-check wouldn’t be able to parse understand precompiled headers built with clang, which is actually something explicitly tested in the test suite.</div><div><br class=""></div><div>That said, there are a couple of libraries in that list that look like we should definitely be able to get rid of (Instrumentation, and all the optimizations like ObjCArcOpts, ScalarOpts, Vectorize, ...) since we are only compiling metadata and no code.</div><div>I will investigate what’s necessary to get rid of these unnecessary dependencies.</div><div><br class=""></div>-- adrian</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Jul 8, 2015 at 6:12 PM, Manuel Klimek <span dir="ltr" class=""><<a href="mailto:klimek@google.com" target="_blank" class="">klimek@google.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class="gmail_quote"><div class=""><div class="h5"><div dir="ltr" class="">On Wed, Jul 8, 2015 at 6:10 PM Adrian Prantl <<a href="mailto:aprantl@apple.com" target="_blank" class="">aprantl@apple.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 8, 2015, at 9:03 AM, Manuel Klimek <<a href="mailto:klimek@google.com" target="_blank" class="">klimek@google.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div dir="ltr" class="">On Wed, Jul 8, 2015 at 5:53 PM Adrian Prantl <<a href="mailto:aprantl@apple.com" target="_blank" class="">aprantl@apple.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> On Jul 8, 2015, at 5:04 AM, Manuel Klimek <<a href="mailto:klimek@google.com" target="_blank" class="">klimek@google.com</a>> wrote:<br class="">
><br class="">
> 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 :)<br class="">
><br class="">
<br class="">
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.<br class="">
<br class="">
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.</blockquote><div class=""><br class=""></div><div class="">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 ;)</div></div></div>
</div></blockquote></div><br class=""></div><div style="word-wrap:break-word" class=""><div class="">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.</div><div class="">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. </div></div></blockquote><div class=""><br class=""></div></div></div><div class="">Makes sense, thanks! </div></div></div>
</blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>