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

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>

As I think I said elsewhere, I find it weird that LLVM tools accept long
arguments with a single dash, and I'd be happy for the binary utilities at
least to move away from this approach, if it improves compatibility/reduces
gotchas etc. One of the points from the BoF on the LLVM binutils at the
recent Euro LLVM developers' meeting was that if we are going to break
compatibility with previous versions of LLVM, we're better off doing it
now, rather than leaving it a long time. The longer it gets left, the more
users, and therefore the more likely somebody has come to rely on it in a
non-trivial-to-fix way.

If we are particularly concerned with llvm-readobj, we could (if it is
practical) try handling it differently to llvm-readelf. An approach as
suggested by Michael Spencer at the BoF could be to migrate away from using
cl::opt and follow the same route as llvm-objcopy. That would allow us to
have different option sets for the two versions of that tool, if we wanted.

On Tue, 16 Apr 2019 at 08:44, Jordan Rupprecht <rupprecht at google.com>
wrote:
> 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/f41be7fc/attachment.html>

It's actually a bit weirder than you might think.  The CommandLine parser
will happily eat as many dashes as you care to write, e.g., `----sections`
is the same as `-sections`.


On Tue, Apr 16, 2019 at 2:11 AM James Henderson via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> As I think I said elsewhere, I find it weird that LLVM tools accept long
> arguments with a single dash, and I'd be happy for the binary utilities
at
> least to move away from this approach, if it improves compatibility/reduces
> gotchas etc. One of the points from the BoF on the LLVM binutils at the
> recent Euro LLVM developers' meeting was that if we are going to break
> compatibility with previous versions of LLVM, we're better off doing it
> now, rather than leaving it a long time. The longer it gets left, the more
> users, and therefore the more likely somebody has come to rely on it in a
> non-trivial-to-fix way.
>
> If we are particularly concerned with llvm-readobj, we could (if it is
> practical) try handling it differently to llvm-readelf. An approach as
> suggested by Michael Spencer at the BoF could be to migrate away from using
> cl::opt and follow the same route as llvm-objcopy. That would allow us to
> have different option sets for the two versions of that tool, if we wanted.
>
> On Tue, 16 Apr 2019 at 08:44, Jordan Rupprecht <rupprecht at
google.com>
> wrote:
>
>> 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
>>>
>> _______________________________________________
> 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/98ff0763/attachment.html>