<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 6, 2014 at 3:22 PM, Chris Bieneman <span dir="ltr"><<a href="mailto:beanz@apple.com" target="_blank">beanz@apple.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>The other thought I had which motivated this solution was that if we could strip all the functionality that is only really used by tools out into a separate library it would offer cleaner organization of code. Support seems to often get used as a dumping ground for stuff that just doesn’t fit anywhere else.</div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Based on your feedback and Chandler’s maybe this just isn’t the right separation. I can look into a solution to address our hackiness without creating a separate library.</div></div></blockquote><div><br></div><div>What other stuff do you think belongs in ToolsSupport that doesn't belong in Support? Looking back at the initial email, you have command line parsing and ToolOutputFile.</div><div><br></div><div>We could split out command line parsing, but it doesn't seem worth it, given that we're still carrying regex support, Unicode conversion, dynamic library support, and other things that probably aren't absolutely necessary.</div><div><br></div><div>What about splitting out a CrashRecovery library instead? That seems a lot more targeted and meaningful. We'd probably put ToolOutputFile.cpp in there.</div></div></div></div>