<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="">I think for the main goal of cleaning up the Mac-specific hack, a CrashRecovery library would work equally well. Juergen is more familiar with the WebKit side of things, so he may be aware of something I’m not thinking of.<div class=""><br class=""></div><div class="">Chandler, does splitting out a CrashRecovery library instead seem sane?</div><div class=""><br class=""></div><div class="">Other than code organization and naming, the general idea of splitting out a CrashRecovery library would be the same as the other patches I sent out. I was thinking of taking the approach of moving one symbol, fixing everything, then repeat.</div><div class=""><br class=""></div><div class="">Does that seem like the right approach?</div><div class=""><br class=""></div><div class="">-Chris</div><div class=""><div class=""><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Nov 6, 2014, at 3:43 PM, Reid Kleckner <<a href="mailto:rnk@google.com" class="">rnk@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 6, 2014 at 3:22 PM, Chris Bieneman <span dir="ltr" class=""><<a href="mailto:beanz@apple.com" target="_blank" class="">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" class=""><div class="">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 class=""> </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" class=""><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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>
</div></blockquote></div><br class=""></div></div></div></body></html>