Fāng-ruì Sòng via llvm-dev
2019-Apr-16 06:41 UTC
[llvm-dev] 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>
Rui Ueyama via llvm-dev
2019-Apr-16 06:59 UTC
[llvm-dev] Accept --long-option but not -long-option for llvm binary utilities
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>
Jordan Rupprecht via llvm-dev
2019-Apr-16 07:43 UTC
[llvm-dev] 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>
Reid Kleckner via llvm-dev
2019-Apr-19 18:13 UTC
[llvm-dev] Accept --long-option but not -long-option for llvm binary utilities
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>
Fāng-ruì Sòng via llvm-dev
2019-Apr-20 07:31 UTC
[llvm-dev] Accept --long-option but not -long-option for llvm binary utilities
> 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>
Possibly Parallel Threads
- Accept --long-option but not -long-option for llvm binary utilities
- Accept --long-option but not -long-option for llvm binary utilities
- Accept --long-option but not -long-option for llvm binary utilities
- [llvm-readobj][RFC]Making llvm-readobj GNU command-line compatible
- [llvm-readobj][RFC]Making llvm-readobj GNU command-line compatible