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

[Rui Ueyama via llvm-dev]

That change makes sense to me. I'd like to note that the policy should be
set per-command basis, as some commands are required to accept both `--`
and `-` for long option names. lld is such command.

On Tue, Apr 16, 2019 at 3: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190416/330e93c5/attachment.html>