<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">-Chris</div><div><br class=""><blockquote type="cite" class=""><div class="">On Oct 31, 2018, at 8:51 AM, Zachary Turner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">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 class=""><div class="gmail_quote"><div dir="ltr" class="">On Wed, Oct 31, 2018 at 6:20 AM whitequark via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""></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 class="">
> I like this proposal, personally. I'm not too familiar with the<br class="">
> command-line stuff, but my experience is that seeing options relating<br class="">
> to the LLVM backend in binary dumping and manipulation tools seems a<br class="">
> bit weird.<br class="">
<br class="">
I second this! I am very much looking forward to using the llvm-mc tools<br class="">
as a binutils replacement both in my toolchains and manually, and <br class="">
llvm::cl<br class="">
is not being very cooperative when defining the kind of argument parser<br class="">
interface this requires.<br class="">
<br class="">
> <br class="">
> This might be out of scope, but specifically regarding llvm-objdump, I<br class="">
> noted a number of places where the options is MachO specific, and I<br class="">
> was wondering if we could find a way to keep those options separate<br class="">
> from the others, to make it more friendly to those who care about only<br class="">
> ELF, for example.<br class="">
> <br class="">
> On Wed, 31 Oct 2018 at 09:02, Kristina Brooks via llvm-dev<br class="">
> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class="">
> <br class="">
>> Hi,<br class="">
>> <br class="">
>> Just wanted to ask, does anyone have any objections to me working on<br class="">
>> refactoring<br class="">
>> a few common LLVM tools (objdump, nm, strings, readobj) to use the<br class="">
>> new TableGen<br class="">
>> based option interfaces and submitting a diff for each one? Just<br class="">
>> wondering if<br class="">
>> anyone else is currently working on this and so I don't end up doing<br class="">
>> redundant<br class="">
>> work as there were a few discussions regarding `llvm::cl` and I<br class="">
>> think there is<br class="">
>> a general agreement in that that should be something for LLVM parts<br class="">
>> to expose<br class="">
>> various tinkering options, not for handling regular tools.<br class="">
>> <br class="">
>> Especially considering there were a few points raised regarding<br class="">
>> threading and<br class="">
>> the global state of these options, I think this is one of the few<br class="">
>> places I can<br class="">
>> be useful and address part of the problem by moving those<br class="">
>> interfaces.<br class="">
>> <br class="">
>> I also want to improve the quality of help for those tools overall<br class="">
>> to match their<br class="">
>> GNU counterparts more closely and possibly add options for colorful<br class="">
>> output where<br class="">
>> it makes sense and makes it easier to read things like section dumps<br class="">
>> of ELF objects<br class="">
>> for example.<br class="">
>> <br class="">
>> Is anyone currently working on this and if not, how does the overall<br class="">
>> community<br class="">
>> feel about me approaching those things with differentials on<br class="">
>> tool-by-tool basis<br class="">
>> just to improve the overall experience of using those tools (instead<br class="">
>> of getting<br class="">
>> a lot of not-so-relevant information from `llvm-objdump --help`)?<br class="">
>> <br class="">
>> Let me know what you think and if someone is already working on some<br class="">
>> or all o<br class="">
>> these tools in which case I could perhaps focus on others?<br class="">
>> <br class="">
>> Thank you for your time reading this.<br class="">
>> - Kristina<br class="">
>> <br class="">
>> _______________________________________________<br class="">
>> LLVM Developers mailing list<br class="">
>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
> _______________________________________________<br class="">
> LLVM Developers mailing list<br class="">
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
<br class="">
-- <br class="">
whitequark<br class="">
_______________________________________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
</blockquote></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></body></html>