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

[Zachary Turner via llvm-dev]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181031/2c6e28d5/attachment-0001.html>