[llvm-dev] libOption

[Chris Bieneman via llvm-dev]

Kinda. There is no way to restrict which options cl::opt will respect. It will always support parsing all options. That is the biggest reason why I recommend people not use it.

There is however a way to hide options. If you look at clang-format there is an API cl::HideUnrelatedOptions which can be used to hide options that are not in specified categories. That allows you to cater your —help spew.

-Chris

> On Apr 20, 2016, at 8:42 AM, Paweł Bylica via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Can the cl::opt be used in the way where all options from LLVM libraries are not exposed by default? I used it for a small project where I try to avoid dependencies other than LLVM. The issue is the result of `my-project -help` is a mix of my options and LLVM options.
> 
> On Wed, Apr 20, 2016 at 10:29 AM Russell Wallace via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> Okay, that makes sense, thanks. I'll go with cl::opt, then.
> 
> On Wed, Apr 20, 2016 at 8:08 AM, Sean Silva <chisophugis at gmail.com <mailto:chisophugis at gmail.com>> wrote:
> libOption's key feature is being able implement command line parsing compatible with basically any program under the sun. For example, you have control over distinguishing between `-foo` and `--foo` if you need that. 
> It is used in clang for command line parsing compatible cl.exe and gcc.
> In LLD it is used for command line option parsing compatible with link.exe, gnu ld, and ld64.
> If you're writing a program from scratch, this is probably too heavyweight and not the right choice (e.g. it involves running a TableGen step as part of your build).
> 
> On the other hand, cl::opt has its oddities. But overall cl::opt is a reasonable basic option parsing library I would say. If you just need some basic option parsing, already have LLVM as a dependency, and don't want to roll your own option parsing, it is probably a decent choice.
> 
> Overall I would not consider LLVM to provide a general purpose "option parsing" solution. But cl::opt is the closest thing we have.
> 
> -- Sean Silva
> 
> On Tue, Apr 19, 2016 at 5:47 AM, Russell Wallace via llvm-dev <llvm-dev at lists.llvm.org <mailto: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 <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <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/20160426/17d25913/attachment-0001.html>