<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 19, 2013 at 3:50 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank" class="cremed">rnk@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Mon, Aug 19, 2013 at 3:20 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank" class="cremed">chandlerc@google.com</a>></span> wrote:<br>
</div><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 dir="ltr"><div class="im"><div>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:</div>

</div><div class="im"><div class="gmail_extra"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
> 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><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></div></div></blockquote><div><br></div><div>I was pushing back against more options.  Less options means a simpler configuration matrix.</div><div class="im"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><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><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></div></blockquote><div><br></div></div><div>To me, #2 seems really close to #1.  Who knows, people using llvm-as-a-library might actually want to write FileCheck and lit tests because it's convenient.</div>
</div></div></blockquote></div><br></div><div class="gmail_extra">I don't think any of these other tools are in an even semi-reasonable state to be installed on a machine in say, /usr/bin. Do you really think we should install /usr/bin/not? /usr/bin/count?</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">That's why I'm pushing for this. I think as we start to have increased usage of the install action by users, this will increasingly be the right set to install. As it stands, distributions are having to pull these overly-general binaries out of the install. =/</div>
</div>