[llvm] r200858 - Revert "Fix an invalid check for duplicate option categories."
Jordan Rose
jordan_rose at apple.com
Wed Feb 12 13:11:27 PST 2014
On Feb 7, 2014, at 9:49 , Alexander Kornienko <alexfh at google.com> wrote:
> On Fri, Feb 7, 2014 at 6:29 PM, Jordan Rose <jordan_rose at apple.com> wrote:
>
> On Feb 6, 2014, at 1:50 , Alexander Kornienko <alexfh at google.com> wrote:
>
>> On Thu, Feb 6, 2014 at 5:03 AM, Jordan Rose <jordan_rose at apple.com> wrote:
>> 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.
>>
>> <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>
>>
>> Okay, rant aside, I think we should get loadable bundles building without linking in LLVM libraries. That doesn't help if two plugins share a static library that the main executable doesn't include, but Support certainly isn't going to be one of those.
>>
>> 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.
>
> *sigh* Yes, all right. :-)
>
> (The *sigh* is that I haven't touched those examples in over a year.)
>
> Thanks!
> Committed revision 200981.
Clang plugins converted to loadable modules in r201256. Let's see if the workaround can come out now!
Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140212/7e3d4130/attachment.html>
More information about the llvm-commits
mailing list