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

[Jordan Rupprecht via llvm-dev]

For binutil compatibility, and in general for any new tools, this sounds
reasonable to me. But I'd worry that things like llvm-readobj have existed
for a long time and people are used to flags like "-sections", and it may
be complicated to change that now. (I guess this RFC is a check to see if
this is true for anyone on the mailing list).

What happens if you make this change and someone does use "-sections" --
will the command line parser suggest "--sections", or will it just fail
because one of -s, -e, -c, etc. is not a valid option?

On Tue, Apr 16, 2019 at 9:00 AM Rui Ueyama via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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
>>
> _______________________________________________
> 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/d8b1970e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4849 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190416/d8b1970e/attachment.bin>