[llvm-dev] Accept --long-option but not -long-option for llvm binary utilities

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

>
> Did you mean --long-option (double-dash), or -long-option (single dash)?
>

Sorry I made a typo :(

In these GNU binutils replacements (llvm-objcopy llvm-readelf llvm-objdump
...) we have many short options that can be grouped (cl::Grouping). I meant
to keep --long-option but drop -long-option. The scope of this RFC is
restricted to these utilities.

In other (regular) utilities (opt llc lli llvm-as ...) we don't use grouped
syntax and there is no confusion at all. People (me included) who are used
to double dash options may find -long-option weird. However, changing those
utilities would be too disruptive.


> Single-dash variants look *very* unusual, i personally never seen them
> used elsewhere.
> It would be good to try to converge on double-dash variant.
>
> Dropping support for double-dash variants instead seems rather disruptive,
> especially since that will prevent usage of llvm tools as drop-in
> replacement for GNU tools.
>
> > (people sometimes call them LLVM binary utilities): llvm-objcopy
> (D60439), llvm-ar, llvm-size, llvm-nm, etc. llvm-objdump (not sure what to
> do with mach-o specific dump options), llvm-readelf (not sure what to do
> with llvm-readobj)
> >
> > On Sat, Apr 20, 2019 at 2:13 AM Reid Kleckner <rnk at google.com> wrote:
> >>
> >> Are you proposing to make this the new style across all LLVM utilities?
> That seems needlessly disruptive. There are plenty of scripts that call
> `opt` and `llc` directly with single dash long options, regardless of how
> much we claim that they are not public facing, and are only developer tools.
> >>
> >> If you want to add a flag to ParseCommandLineOptions so that individual
> LLVM tools can opt into the new behavior gradually, I think that would be
> reasonable.
> >>
> >> On Mon, Apr 15, 2019 at 11:41 PM Fāng-ruì Sòng via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >>>
> >>> Many llvm utilities use cl::ParseCommandLineOptions()
> (include/Support/CommandLine.h) to parse command line options. The cl
> library accepts both -long-option and --long-option forms, with the single
> dash form (-long-option) being more popular.
> >>>
> >>> We also have many binary utilities (llvm-objcopy llvm-objdump
> llvm-readobj llvm-size ...) whose names reflect what they imitate. For
> compatibility with GNU binutils (and some Unix utilities transitively),
> these utilities accept many short options. People who use llvm utilities as
> replacement of GNU binutils may use the grouped option syntax (POSIX
> Utility Conventions), e.g. -Sx => -S -x, -Wd => -W -d, -sj.text => -s
> -j.text
> >>>
> >>> The problem is, grouped short options don't play well with
> -long-option. Sometimes there can be ambiguity. The issue is more prominent
> if the short option accepts an argument.
> >>>
> >>> An approach to prevent the ambiguity is to just disallow -long-option.
> >>> In D60439, I plan to make llvm-objcopy accept --long-option but not
> -long-option.
> >>> It will make its command line option parsing behave more like GNU
> objcopy and less like a regular llvm utility. What do people think of the
> divergence?
> >>>
> >>> Further, can we make similar changes to other llvm binary utilities
> (their names give people the expectation), especially those with many short
> options such as llvm-objdump and llvm-readobj? llvm-readobj behaves like
> GNU readelf if you name it "llvm-readelf". (I don't suggest disallowing
> -long-option for utilities other than binutils)
> >>>
> >>> (Note, llvm-objcopy is a new member of the family and it uses tablegen
> based include/llvm/Option/Opton.h, instead of cl:: as other utilities do.)
> >>>
> >>>
> >>>
> >>> --
> >>> 宋方睿
> >>> _______________________________________________
> >>> LLVM Developers mailing list
> >>> llvm-dev at lists.llvm.org
> >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
> >
> >
> > --
> > 宋方睿
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> Roman
>


-- 
宋方睿
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190421/958d02d4/attachment.html>