
<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 Nov 6, 2014, at 3:00 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 2:42 PM, Juergen Ributzka <span dir="ltr" class=""><<a href="mailto:juergen@apple.com" target="_blank" class="">juergen@apple.com</a>></span> wrote:<br class=""><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="">I would have preferred the library to be moved out of the “Support” folder and have its own top-level library and include folder.</div></div></blockquote><div class=""><br class=""></div><div class="">+1, you will need to do this if you want to support the autoconf build system.</div></div></div></div></div></blockquote><div><br class=""></div>This should be a fairly small change to make.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">----</div><div class=""><br class=""></div><div class="">Looking at the diff, I now remember why you want to do this. I seem to recall you want to do this because the Mac-specific code in Support defines raise(), __assert_rtn(), and abort(), and that's hostile to embedders like WebKit. Makes sense, it's a gross hack, and I'd be in favor of fixing it if possible. If it weren't for this hack, I would recommend that you just avoid calling PrintStackTraceOnErrorSignal from WebKit.</div></div></div></div></div></blockquote><div><br class=""></div><div>That hack is the primary motivator, but that can be solved other ways. One option would be for us to move the nasty Mac-specific hack out of the cpp file and into a header that tools could optionally include.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">Is there some way we can prevent this Mac-specific hack from affecting our library organization? It's not clear to me that the distinction between Support and ToolsSupport is really worth it.</div><div class=""><br class=""></div><div class="">Most LLVM tools are single threaded and don't need to redirect signals to the current thread. I think it's only the crash recovery logic that needs the signal to be delivered to the current thread. Maybe we should factor out a CrashRecovery library, given that XCode via libclang is basically the only client of this stuff? Does WebKit want to try to recover from JIT assertion failures?</div></div></div></div>

</div></blockquote></div><br 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 class=""><br class=""></div><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 class=""><br class=""></div><div class="">-Chris</div></body></html>