[llvm-dev] Binary utilities: switch command line parsing from llvm::cl to OptTable (byproduct: drop -long-option?)

[Fāng-ruì Sòng via llvm-dev]

On Mon, Jul 5, 2021 at 9:43 AM Philip Reames <listmail at philipreames.com>
wrote:

>
> On 7/2/21 10:14 AM, Fāng-ruì Sòng via llvm-dev wrote:
>
> llvm/tools/ include some binary utilities used as replacement for GNU
> binutils, e.g. llvm-objcopy, llvm-symbolizer, llvm-nm.
> In some old threads people discussed some drawbacks of using cl::opt for
> user-facing utilities (I cannot find them now).
> Switching to OptTable is an appealing solution. I have prepared two
> patches for two binary utilities: llvm-nm and llvm-strings.
>
> * llvm-strings https://reviews.llvm.org/D104889
> * llvm-nm https://reviews.llvm.org/D105330
>
> llvm-symbolizer was switched last year. llvm-objdump was switched by
> thakis earlier this year.
>
> The switch can fix some corners with lib/Support/CommandLine.cpp. Here is
> a summary:
>
> * -t=d is removed (equal sign after a short option). Use -t d instead.
> * --demangle=0 (=0 to disable a boolean option) is removed. Omit the
> option or use --no-demangle instead.
>
> To me, removing these would make the interface *worse*.  This is purely
> subjective, but I use the second item regularly when locally debugging to
> swap back and forth between two modes easily
>
See Medhi's message: "I think part of the confusion on my side in this
thread is that when I read "binary utilities" I thought first and foremost
about `opt` and `lld`, while you're using "binary utilities" to refer to
what I would call "end-user tools". I agree with you that tools like clang
and lld are in a different category than `opt`."

The proposal is for
llvm-{ar,cov,cxxfilt,nm,objcopy,objdump,readobj,size,strings,symbolizer}.
The options mostly follow GNU, with a few LLVM extensions. There are really
few options which default to true and may be toggled by users to false.
When they have toggles, there are `--no-*` options.

It's not like opt or llc where you need something like -enable-new-pm=0 or
-enable-lto-internalization=0

* To support boolean options (e.g. --demangle --no-demangle), we don't need
> to compare their positions (if (NoDemangle.getPosition() >
> Demangle.getPosition()) , see llvm-nm.cpp)
>
> * grouped short options can be specified with one line
> `setGroupedShortOptions`, instead of adding cl::Grouping to every short
> options.
> * We don't need to add cl::cat to every option and call
> `HideUnrelatedOptions` to hide unrelated options from --help. The issue
> would happen with cl::opt tools if linker garbage collection is disabled or
> libLLVM-13git.so is used. (See https://reviews.llvm.org/D104363)
> * If we decide to support binary utility multiplexting (
> https://reviews.llvm.org/D104686), we will not get conflicting options.
> An option may have different meanings in different utilities (especially
> for one-letter options).
>
> *I expect that most users will not observe any difference.*
>
> There is a related topic whether we should disallow the single-dash
> `-long-option` form.
> (Discussed in 2019:
> https://lists.llvm.org/pipermail/llvm-dev/2019-April/131786.html Accept
> --long-option but not -long-option for llvm binary utilities)
> *I'd like to disallow -long-option but may want to do this in a separate
> change.*
> The main point is that (1) grouped short options have syntax conflict with
> one-dash long options. (2) the GNU getopt_long style two-dash long option
> is much more popular.
>
> I can think of potential pushback for some Mach-O specific options, e.g.
> nm -arch
> http://www.manpagez.com/man/1/nm/osx-10.12.6.php says `-arch` has one
> dash.
> If such options may have problems, we can keep supporting one dash forms.
> With OptTable, allowing one-dash forms for a specific option is easy.
>
> _______________________________________________
> LLVM Developers mailing listllvm-dev at lists.llvm.orghttps://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/20210705/08a1812f/attachment.html>