llvm dev - Jun 2016 - Supporting sub commands in LLVM command line tools

Hi all,

I've written a patch <http://reviews.llvm.org/D21485> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160618/c6f77a90/attachment.html>

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.

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 <http://reviews.llvm.org/D21485> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160617/fc76f3b0/attachment.html>

Not sure I follow how this would work.  "llvm" is an executable, and
"opt"
is a symlink to "llvm"?  How does llvm then detect that it needs to
use the
opt set of commands?

That said, in principle sure you could have "llvm opt <opt-specific
command
syntax>" or "llvm llc <llc options>".  At some point
you'd probably need to
extend this to support nested subcommands, which I didn't attempt here.

On Fri, Jun 17, 2016 at 6:58 PM Mehdi Amini <mehdi.amini at apple.com>
wrote:
> 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.
>
> 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 <http://reviews.llvm.org/D21485> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160618/dc665bdb/attachment.html>

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

On 18 June 2016 at 02:58, Mehdi Amini via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> I haven't looked at the implementation, but conceptually this looks
nice!
Indeed, really 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.
I think this would muddle things, but it would also help merge all
command line options (ex. -mtriple vs. -triple vs -target).

The only way I know we could solve the dependency, though, is if there
was a binary called "llvm-mc" from "llvm-mc.cpp" which
provided its
own view of the "llvm-mc" functionality (ie. just a shell), and
"llvm"
would be also just a shell to all of them together.

So, "ninja llvm" would build all tools, while "ninja
llvm-mc" would
only build one of them. Now, how do you then transform from a binary
called "llvm-mc" to a symlink to "llvm", it'd probably
happen at
install time if you choose to install "developer tools", which I find
quite useful from say, an "llvm-dev" package.

> This is a bit orthogonal to what you’re doing, but I assume your patch
would
> help to build such an option right?
Unless you're proposing to move from "llvm-mv" to "llvm
mc", I don't
see how this could...

cheers,
--renato