libOption

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.

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).

cl::opt encourages global options, which has been a mixed blessing and curse.

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

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

For what it’s worth (and that is probably not a whole lot! :wink: ), I’m using cl::opt in my Pascal compiler. I can’t say I’ve done extensive work with it, but it’s “doing the job for what I need”.

For reference:
https://github.com/Leporacanthicus/lacsap/blob/master/lacsap.cpp#L35

Okay, that makes sense, thanks. I’ll go with cl::opt, then.

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.

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