[llvm-dev] Supporting sub commands in LLVM command line tools

Justin Bogner via llvm-dev
Sat, 18 Jun 2016 06:20:26 -0000

Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org>
writes:
> Hi,
>
> I haven't looked at the implementation, but conceptually this looks
nice!
>
> We talked internally about an option to build something like a single
"llvm"
> binary that would be symlinked by opt/llc/etc. So that when you invoke
`opt`,
> it would run the same binary but internally the right subcommand set of
> options would be used. The downside is that running `ninja llvm-mc` would
> depends on every LLVM libraries though.

Why would you want that? I build specific tools an order of magnitude
more often than building all of them, so personally I would consider
this downside really critical.

> This is a bit orthogonal to what you’re doing, but I assume your patch
would
> help to build such an option right?
>
> —
> Mehdi
>
>     On Jun 17, 2016, at 5:00 PM, Zachary Turner via llvm-dev <
>     llvm-dev at lists.llvm.org> wrote:
>
>     Hi all,
>
>     I've written a patch to support subcommands in llvm command line
tools.
>     This potentially has broad interest (either positive or negative), so I
>     figured I'd give a heads up here instead of just on llvm-commits.
>
>     The motivation for this is that we frequently have tools with
incompatible
>     sets of command line options.  I ran into this on llvm-pdbdump and was
>     debating breaking off some of the functionality into a separate tool to
>     make the command line interface more sensible, and to prevent people
>     getting confused about which options could be used with which other
>     options.
>
>     A better approach to this, in my opinion, is the use of sub commands.
>     This way all the options that can be used together are grouped
together,
>     and you simply can't specify incompatible options at the same time.
>
>     There is more information in the patch, including some examples of what
it
>     looks like, so if you're interested in this or have a strong
opinion one
>     way or the other, let me know.
>
>     Note that this is an **opt in** feature, and if you continue using
cl::opt
>     as you always have, this change should be invisible to you.