<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Jun 2, 2017 at 11:44 AM Zachary Turner <<a href="mailto:zturner@google.com">zturner@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Jun 2, 2017 at 11:23 AM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'm still missing some of the motivation as to 'why', here.<br><br>If there are significant uses of a library that don't use most of it - yeah, i think there's merit in separating things out (eg: if lld, lldb, etc, use, say, the DWARF constants but not the rest of Support/ADT - yeah, it'd be nice if they didn't have to rebuild whenever SmallString changed, for example). (though even then, Ninja's pretty efficient about only rebuilding what it has to, so I'm not sure that even the library granularity changes much about the build performance here - header dependency could be something to care about there, for sure (fewer long chains of dependent headers, breaking a header into two if there's functionality that is used broadly next to functionality that has a narrow use, etc).<br><br>What's the goal/metric/benefit?</div></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div><span style="font-size:13px">First, there is the intangible benefit.  DWARF.h and WASM.h simply do not make logical sense in Support.  </span> This might seem like a minor point, but I put this into the "technical debt" category.  By not enforcing strict guidelines of what goes into Support, we build up technical debt over time as a bunch of unrelated stuff piles into it.  We can do better than this.  </div></div></div></blockquote><div><br>What's the debt, exactly, though? Discoverability for developers? I'm not sure if people will be more likely to know that DWARF.h is there than in Support, but maybe.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>Second, libraries as an abstraction are virtually free, and the point of them is to group related things together.  One could probably even argue they are better than free, as they have less than or equal to zero cost since at worst they do nothing, and at best they speed up your build and reduce your binary size.<br></div></div></div></blockquote><div><br>Having super granular libraries I think may come at some cost - more places to go looking for/wonder if that's where the thing you want is residing.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div>Third, there is the practical benefit.  The only LLVMBuild.txt files modified here are lib/IR and lib/Object.<br></div></div></div></blockquote><div><br>I'm not sure I follow what you mean by that (how the second sentence describes a practical benefit implied by the first)<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div>Any tool that did not depend on one of those two libraries should now build faster and be smaller in binary size. </div></div></div></blockquote><div><br>Why would it be smaller in binary size? Unused code wouldn't be linked in.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> I don't have a list of which tools satisfy that condition, however, but it's definitely non-empty (FileCheck, for example, is an obvious candidate).<br></div></div></div></blockquote><div><br>*nod* Sure enough, though I'd be surprised if that really mattered to any build - modifying DWARF.h will cause you to rebuild something else that'll take a lot longer than FileCheck with or without the change.<br><br>As you say, though, unlikely to be harmful - but confusing to me.<br><br>Carry on :)<br> </div></div></div>