<div dir="ltr">On Fri, Aug 16, 2013 at 6:45 PM, Hans Wennborg <span dir="ltr"><<a href="mailto:hans@chromium.org" target="_blank" class="cremed">hans@chromium.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Fri, Aug 16, 2013 at 5:07 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" class="cremed">chandlerc@google.com</a>> wrote:<br>

> On Fri, Aug 16, 2013 at 4:57 PM, Reid Kleckner <<a href="mailto:rnk@google.com" class="cremed">rnk@google.com</a>> wrote:<br>
>><br>
>> On Fri, Aug 16, 2013 at 4:22 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" class="cremed">chandlerc@google.com</a>><br>
</div><div class="im">> Yea, sorry, didn't mean to imply that it would change the defaults. =] I'm<br>
> actually *asking* for a change to the defaults.<br>
><br>
>><br>
>> Do you think it's worth adding another option to separate "only install<br>
>> toolchain binaries" from "don't install development resources"?  If we can<br>
>> get by with fewer options, that seems better.<br>
><br>
><br>
> I do think so. I think there are three classes of users:<br>
><br>
> 1) People working directly on LLVM or LLVM projects (LLD, Clang, something<br>
> else that directly shares the development infrastructure like build systems,<br>
> tablegen, and lit).<br>
<br>
</div>This is what "make install" provides for today.<br>
<div class="im"><br>
> 2) People using LLVM, both as a library and potentially the command line<br>
> tools and toolchain, to build other pieces of software. This would include<br>
> users of LLVM inside of a JIT, interpreter, etc.<br>
<br>
</div>So this is #1 minus tablegen, lit and build system files?<br></blockquote><div><br></div><div>Yes, and some other stuff (FileCheck?)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
> 3) People using LLVM+Clang(+LLD)?(+LLDB)? only as a C/C++/ObjC/ObjC++<br>
> toolchain (including the linker and debugger in that as necessary) for their<br>
> development. They don't use any of the libraries, but do use very end-user<br>
> tools like clang-format, clang-check, libclang.so (for their editor), etc.<br>
<br>
</div>This is what you get if you set LLVM_INSTALL_DEV_FILES=OFF from my<br>
patch, and use the existing LLVM_BUILD_TOOLS=OFF (disables building<br>
llc, opt, etc.).<br></blockquote><div><br></div><div>Ok, maybe the naming is just confusing. I'm happy if the result of my comment is to keep the same functionality, but split it up into different named options. I think that would help.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> The only people who need #1 to be supported by the *install* are people<br>
> building LLVM projects in a stand-alone way from the core. There are several<br>
> people at Apple that do this for Clang because xcode is happier with the<br>
> project files that way. I think they could probably enable a default-off<br>
> feature to get this.<br>
<br>
</div>Are you saying that you'd like #2 to be the default instead of #1?<br></blockquote><div><br></div><div>Yes. I'd like #1 to be an easy opt-in for folks who need it. AFAIK, this is an important but not terribly common use case.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">> While I would *like* for usecase #3 to go away (as #2 is a strict superset).<br>
> I'm happy with the defaults assuming that #3 doesn't exist. However, I<br>
> suspect as long as we produce static libraries for everything *and*<br>
> statically link all the tools, #3 is a useful thing to provide.<br>
<br>
</div>I'm not following here. Why do you want #3 to go away, isn't this the<br>
typical use case for the end-user who just wants a toolchain? #3 is<br>
the case I'm trying to enable :)<br></blockquote><div><br></div><div>Sorry, my "like" here was "in a beautiful ideal world where I get to ignore the reality of where we are today". ;] Essentially, it would be nice (in an idealistic sense) if all of the users of Clang/LLVM were interested in using the *libraries* in addition to the basic toolchain when appropriate.</div>
<div><br></div><div>But the reality is that most folks using these things today are really interested in C++ compiler, and we should provide a quick and easy way to get one.</div></div></div></div>