llvm dev - Nov 2018 - Migrating llvm-objdump and a few other common binutils replacements away from llvm::cl.

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.

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).

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.

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

The way I think about libOption vs cl:::opt is:

- cl::opt: use it for convenience and simplicity
- libOption: use it for when you need to be compatible with a particular
command line flag format.

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.

Example:
$ objdump -d a.out
$ objdump --disassemble a.out
$ objdump -disassemble a.out

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.


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.

(also, btw, you an probably add llvm-ar to your list of tools that need a
command-line facelift)

-- Sean Silva

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