[llvm-dev] libOption

[Sean Silva via llvm-dev]

On Tue, Apr 19, 2016 at 8:47 AM, Reid Kleckner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Honestly I don't know if I would recommend using libOption or cl::opt if
> you're making a new tool with a new command line interface.
>
> libOption evolved out of Clang, and its primary goal was to parse
> GCC-style command lines, which don't follow the rules of cl::opt. We reused
> it for LLD since it has similar parsing issues, but if you don't have those
> challenges, it's kind of heavyweight. Oh, and our usage of it is generally
> O(n^2) in the command line length, because finding the last flag is linear (
> https://llvm.org/bugs/show_bug.cgi?id=20999).
>

And surprisingly this O(n^2) behavior has never shown up on general
compilation profiles (otherwise it would probably be fixed in a hurry).


-- Sean Silva


>
> cl::opt encourages global options, which has been a mixed blessing and
> curse.
>
> On Tue, Apr 19, 2016 at 5:47 AM, Russell Wallace via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> I'm given to understand that the recommendation these days is to use
>> libOption instead of cl::opt, on the grounds that it has a number of
>> advantages including more control of which options are made available.
>>
>> Is there any information available on how to use libOption, any
>> documentation or example programs? Do any existing programs use it except
>> the clang driver programs? Those customise their commandline handling
>> heavily enough that it's hard to use them as examples.
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160419/9d8372f0/attachment.html>