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

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

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.)



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