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

Justin Bogner via llvm-dev llvm-dev at lists.llvm.org
Fri Jun 17 23:20:26 PDT 2016

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

More information about the llvm-dev mailing list