<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="auto">The way I think about libOption vs cl:::opt is:<div dir="auto"><br></div><div dir="auto">- cl::opt: use it for convenience and simplicity</div><div dir="auto">- libOption: use it for when you need to be compatible with a particular command line flag format.</div><div dir="auto"><br></div><div>My understanding is taht cl::opt just doesn't have the fine-grained control needed for a truly production-quality command line interface compatible with some existing tool. I think this is a matter of correctness: is it a requirement to parse the command line options in the same way as some existing program? If so, then cl::opt probably isn't flexible enough. It may get you 90% of the way there, maybe 95%, but it will probably never truly feel native to users of the tool that it is intended to be compatible with.</div><div><br></div><div>Example:</div><div>$ objdump -d a.out<br></div><div>$ objdump --disassemble a.out</div><div>$ objdump -disassemble a.out</div><div><br></div><div>GNU objdump does something different for `-disassemble` vs `--disassemble` (I have no idea what it is doing; it's just an example where it does something different). I'm sure there are at least a few other annoying cases like that (not specifically about the number of dashes, but other random weird stuff). I'm not saying the existing GNU objdump behavior is necessarily good, just that if it is a requirement to be compatible, then I think cl::opt just doesn't cut it.</div><div><br></div><div><br></div><div>So from that perspective, I think that moving to libOption instead of cl::opt makes sense for these tools, as I think it is a goal for them to eventually be production-quality drop-in replacements for the existing binutils tools.</div><div><br></div><div>(also, btw, you an probably add llvm-ar to your list of tools that need a command-line facelift)</div><div dir="auto"><br></div><div dir="auto">-- Sean Silva</div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 5, 2018, 3:43 PM Chris Bieneman 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">A long time back, I had a discussion with Chandler about cl::opt, and one of the concerns we had at the time about replacing it all with libOption was that the table gen based options are a bit heavy handed for some of the simpler tools.<div><br></div><div>The idea Chandler had back at the time was to have libOption support a simplified interface for programmatically defining options (something similar to Python's argparse).</div><div><br></div><div>That would make it easy to create small lightweight tools with only a few options and get rid of cl::opt except for as a vehicle for debug options.</div><div><br></div><div>-Chris</div><div><br><blockquote type="cite"><div>On Oct 31, 2018, at 8:51 AM, Zachary Turner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="m_8037822703025785100m_-1330433362698007091Apple-interchange-newline"><div><div dir="ltr">I wish we could migrate all of llvm away from cl::opt to be honest.  The big missing feature is subcommands (which sadly I take the blame for, since I implemented it in cl::opt), which I guess needs to be implemented in lib/Option before we can port everything away from cl::opt.</div><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 31, 2018 at 6:20 AM whitequark via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2018-10-31 10:21, James Henderson via llvm-dev wrote:<br>
> I like this proposal, personally. I'm not too familiar with the<br>
> command-line stuff, but my experience is that seeing options relating<br>
> to the LLVM backend in binary dumping and manipulation tools seems a<br>
> bit weird.<br>
<br>
I second this! I am very much looking forward to using the llvm-mc tools<br>
as a binutils replacement both in my toolchains and manually, and <br>
llvm::cl<br>
is not being very cooperative when defining the kind of argument parser<br>
interface this requires.<br>
<br>
> <br>
> This might be out of scope, but specifically regarding llvm-objdump, I<br>
> noted a number of places where the options is MachO specific, and I<br>
> was wondering if we could find a way to keep those options separate<br>
> from the others, to make it more friendly to those who care about only<br>
> ELF, for example.<br>
> <br>
> On Wed, 31 Oct 2018 at 09:02, Kristina Brooks via llvm-dev<br>
> <<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> <br>
>> Hi,<br>
>> <br>
>> Just wanted to ask, does anyone have any objections to me working on<br>
>> refactoring<br>
>> a few common LLVM tools (objdump, nm, strings, readobj) to use the<br>
>> new TableGen<br>
>> based option interfaces and submitting a diff for each one? Just<br>
>> wondering if<br>
>> anyone else is currently working on this and so I don't end up doing<br>
>> redundant<br>
>> work as there were a few discussions regarding `llvm::cl` and I<br>
>> think there is<br>
>> a general agreement in that that should be something for LLVM parts<br>
>> to expose<br>
>> various tinkering options, not for handling regular tools.<br>
>> <br>
>> Especially considering there were a few points raised regarding<br>
>> threading and<br>
>> the global state of these options, I think this is one of the few<br>
>> places I can<br>
>> be useful and address part of the problem by moving those<br>
>> interfaces.<br>
>> <br>
>> I also want to improve the quality of help for those tools overall<br>
>> to match their<br>
>> GNU counterparts more closely and possibly add options for colorful<br>
>> output where<br>
>> it makes sense and makes it easier to read things like section dumps<br>
>> of ELF objects<br>
>> for example.<br>
>> <br>
>> Is anyone currently working on this and if not, how does the overall<br>
>> community<br>
>> feel about me approaching those things with differentials on<br>
>> tool-by-tool basis<br>
>> just to improve the overall experience of using those tools (instead<br>
>> of getting<br>
>> a lot of not-so-relevant information from `llvm-objdump --help`)?<br>
>> <br>
>> Let me know what you think and if someone is already working on some<br>
>> or all o<br>
>> these tools in which case I could perhaps focus on others?<br>
>> <br>
>> Thank you for your time reading this.<br>
>> - Kristina<br>
>> <br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer" target="_blank">llvm-dev@lists.llvm.org</a><br>
>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br>
-- <br>
whitequark<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer" target="_blank">llvm-dev@lists.llvm.org</a><br><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br></div></blockquote></div><br></div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>