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

[Philip Reames via llvm-dev]

On 7/5/21 10:14 AM, Fāng-ruì Sòng wrote:
> On Mon, Jul 5, 2021 at 9:43 AM Philip Reames 
> <listmail at philipreames.com <mailto: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
>>     <https://reviews.llvm.org/D104889>
>>     * llvm-nm https://reviews.llvm.org/D105330
>>     <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
You're right, I had missed that, and it completely resolves my concern.  
Sorry for the noise.
>
>     * 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 <https://reviews.llvm.org/D104363>)
>>     * If we decide to support binary utility multiplexting
>>     (https://reviews.llvm.org/D104686
>>     <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
>>     <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
>>     <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 list
>>     llvm-dev at lists.llvm.org  <mailto:llvm-dev at lists.llvm.org>
>>     https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev  <https://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/de81ada2/attachment.html>