<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 7, 2014 at 10:57 AM, Daniel Dunbar <span dir="ltr"><<a href="mailto:daniel@zuster.org" target="_blank">daniel@zuster.org</a>></span> wrote:<br><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">1. I would like to see some of the code in LLVM's ADT and Support libraries available for reuse in other projects. This also has some potential for being useful to Clang -- one could imagine a world where Clang directly linked the ADT & Support libraries, but used the compiler itself via a clear dynamic-library vended API (which would be unrealistic to expect the ADT & Support libraries would ever want to provide).</blockquote></div><br>I don't think this is relevant or possible. The IR interfaces used by Clang are extensive and not likely to be reasonable dynamic library vended APIs. And in general, I don't think we should design based on this very speculative future.</div><div class="gmail_extra"><br></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"><span style="font-family:arial,sans-serif;font-size:13px">3. I also see a good argument for having a ToolsSupport library, as a place for all of the very-LLVM(the compiler) specific functionality that would have no place in a shared Support library (for any number of reasons: lack of generality, invasiveness, or because they add substantial other dependencies).</span></blockquote><div><br></div><div>I agree in principle, but I don't think the signal handling or crash recovery are actually relevant for this -- they're very general, just only useful for executable applications as opposed to useful for things like the LLVM libraries in WebKit.</div></div>