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

[Mehdi Amini via llvm-dev]

> On Jun 17, 2016, at 11:20 PM, Justin Bogner <mail at justinbogner.com> wrote:
> 
> Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org <mailto: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 can see three reasons right now:

1) Disk space: the “bin” directory for just llvm (no clang, libc++, etc.) after running dsymutil takes 2.8GB right now.
2) running dsymutil on every binary is taking quite a long time
3) LTO build time would be significantly faster ;)


> 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 would be a build settings, you wouldn’t lose anything if you don’t opt-in.

— 
Mehdi

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