<div dir="ltr">As an aside, now I have a logical place to put lots of stuff related to CodeView record formats.  Not having that is part of why I had to add a dependency from ObjectYAML to DebugInfoCodeView, but once we have that it's conceivable I could get enough of the format definitions moved over to ObjectFormat or BinaryFormat that we won't need this dependency anymore.  But it's spread across 5+ files because there's so much of it, and it would just pollute Support for no good reason if I were to put it there.</div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jun 2, 2017 at 12:44 PM 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:53 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"><div class="gmail_quote"><div dir="ltr">On Fri, Jun 2, 2017 at 11:44 AM Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">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></div><div dir="ltr"><div class="gmail_quote"><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.</div></div></div></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div> I guess it's the same argument you would make to justify any library separation -- Group related things together.  Libraries are more than just a build system implementation detail.</div><div><br></div><div>If the only valid justification for creating a library were to improve some measurable metric in build time then we wouldn't have things like ObjectYAML, we could just put DWARF Yaml code inside of DebugInfo/DWARF, and COFF Yaml code inside lib/Object, etc.  After all, the linker will just strip all the stuff that isn't used, so any tool that doesn't care about converting between binary and yaml formats would be unaffected.  But we put them together because it "makes sense"<span style="color:rgb(34,34,34);font-family:Roboto,arial,sans-serif;font-size:16px">™ </span><span class="m_7476972289263883148inbox-inbox-Apple-converted-space">even though there's only a couple of files.</span></div><div><span class="m_7476972289263883148inbox-inbox-Apple-converted-space"><br></span></div><div><span class="m_7476972289263883148inbox-inbox-Apple-converted-space">Perhaps the debt isn't obvious when llvm/Support "only" has 147 files.  What about when it has 247?  A year ago llvm/Support had only <a href="https://github.com/llvm-mirror/llvm/tree/caeade42341b7b7a14b4e6bd13aeccd4a1da452a/include/llvm/Support" target="_blank">116 files</a>.  I think the barrier to entry for getting stuff in support should be high (and I say this as someone who has dumped some stuff into support because that's what precedent had decided you do when you want to share some code)</span></div></div></div></blockquote></div>