<div dir="ltr"><div dir="ltr">> Are you proposing to make this the new style across all LLVM utilities?<div><br></div><div>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)</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Apr 20, 2019 at 2:13 AM Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 15, 2019 at 11:41 PM Fāng-ruì Sòng via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div>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.</div><div><br></div><div>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</div><div><br></div><div>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.</div><div><br></div><div>An approach to prevent the ambiguity is to just disallow -long-option.</div><div>In D60439, I plan to make llvm-objcopy accept --long-option but not -long-option.</div><div>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?</div><div><br></div><div>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)</div><div><br></div><div>(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.)</div></div><div><br></div><div><br></div><div><br></div>-- <br><div dir="ltr" class="gmail-m_2410513563476010482gmail-m_9135659368618948977gmail_signature"><div dir="ltr">宋方睿</div></div></div></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">宋方睿</div></div>