llvm dev - Apr 2019 - Accept --long-option but not -long-option for llvm binary utilities

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>

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>

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>

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190419/67914ec2/attachment.html>

> Are you proposing to make this the new style across all LLVM utilities?
No. Only drop --long-option for GNU binutils replacements (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
>>
>
-- 
宋方睿
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190420/6d93810f/attachment.html>