<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Feb 7, 2014, at 9:49 , Alexander Kornienko <<a href="mailto:alexfh@google.com">alexfh@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Feb 7, 2014 at 6:29 PM, Jordan Rose <span dir="ltr"><<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</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"><div style="word-wrap:break-word"><br><div><div class=""><div>
On Feb 6, 2014, at 1:50 , Alexander Kornienko <<a href="mailto:alexfh@google.com" target="_blank">alexfh@google.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
On Thu, Feb 6, 2014 at 5:03 AM, Jordan Rose <span dir="ltr"><<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</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"><div style="word-wrap:break-word"><div>It would actually make sense for the plugin not to link LLVM libraries known to be in Clang, but on the flip side it would also make sense for the general option category to not be a static variable.</div>
<div><br></div><div><rant>Honestly, my personal opinion is that the whole CommandLine library is really messed up, and is using global variables and static initialization in pretty much exactly the ways a C++ style guide would tell you not to. :-) (You'll notice how I made a stack-based cl::Option variant when adding unit tests for my recent change.)</rant></div>
<div><br></div><div>Okay, rant aside, I think we should get loadable bundles building without linking in LLVM libraries. That doesn't help if two plugins <i>share</i> a static library that the main executable doesn't include, but Support certainly isn't going to be one of those.</div>
</div></blockquote><div><br></div><div>Are you going to take care of the plugin rework? Is it fine to go with the intermediate solution in the meanwhile? It's strictly better, than the status quo, as it resolves crashes when using -help in the assertions-enabled build with a certain STL implementation.<br>
</div><div></div><div></div></div></div></div></blockquote><div><br></div></div><div>*sigh* Yes, all right. :-)</div><div><br></div><div>(The *sigh* is that I haven't touched those examples in over a year.)</div></div>
</div></blockquote><div><br></div><div>Thanks!</div><div>Committed revision 200981.<br></div></div></div></div></blockquote><br></div><div>Clang plugins converted to loadable modules in r201256. Let's see if the workaround can come out now!</div><div><br></div><div>Jordan</div><br></body></html>