Philip Reames via llvm-dev
2021-Jul-05 16:43 UTC
[llvm-dev] Binary utilities: switch command line parsing from llvm::cl to OptTable (byproduct: drop -long-option?)
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.> * 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 > 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/47122f29/attachment.html>
Fāng-ruì Sòng via llvm-dev
2021-Jul-05 17:14 UTC
[llvm-dev] Binary utilities: switch command line parsing from llvm::cl to OptTable (byproduct: drop -long-option?)
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>