<div dir="ltr">On Fri, Aug 16, 2013 at 4:57 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank" class="cremed">rnk@google.com</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 dir="ltr">On Fri, Aug 16, 2013 at 4:22 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank" class="cremed">chandlerc@google.com</a>></span> wrote:<br>
<div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div><br><div class="gmail_quote">

On Fri, Aug 16, 2013 at 3:48 PM, Hans Wennborg <span dir="ltr"><<a href="mailto:hans@chromium.org" target="_blank" class="cremed">hans@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div style="overflow:hidden">  Change option name to LLVM_INSTALL_DEV_FILES. Also move cmake files and llvm-lit under this flag.<br><br>  (Not changing the code review title to hopefully keep this in the same email thread.)<br>

</div></blockquote></div><br></div>Er, no?</div><div class="im"><div class="gmail_extra"><br></div><div class="gmail_extra">So, first note that this changes users of 'make install' in addition to users of cpack.</div>
<div class="gmail_extra">
<br></div></div><div class="im"><div class="gmail_extra">There are two layers of this:</div><div class="gmail_extra"><br></div><div class="gmail_extra">1) install development tools / resources useful for developing other *LLVM* projects (tblgen, etc)</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">2) install *anything* but executable binaries.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I think these should be different. I think #1 should be default-off and turned on for users of the stand-alone Clang cmake build. It should be called something about "development".</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">I think #2 should be default-on, because many many users of LLVM specifically want the core libraries. I think the best way is to negate the flag: make it INSTALL_TOOLCHAIN_BINARIES_ONLY or something, and when enabled, you only get the binaries used as part of a toolchain (llvm-{ar,nm,dwarfdump,...}, clang, clang-format, etc., but not opt or llc.</div>

</div></div></blockquote></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">First, I just want to make it clear that this patch makes not default behavior change to 'make install' or anything else.  The headers, core libs, etc, are all on by default.</div>
</div></blockquote><div><br></div><div>Yea, sorry, didn't mean to imply that it would change the defaults. =] I'm actually *asking* for a change to the defaults.</div><div> </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">Do you think it's worth adding another option to separate "only install toolchain binaries" from "don't install development resources"?  If we can get by with fewer options, that seems better.<br>
</div></div></blockquote><div><br></div><div>I do think so. I think there are three classes of users:</div><div><br></div><div>1) People working directly on LLVM or LLVM projects (LLD, Clang, something else that directly shares the development infrastructure like build systems, tablegen, and lit).</div>
<div><br></div><div>2) People using LLVM, both as a library and potentially the command line tools and toolchain, to build other pieces of software. This would include users of LLVM inside of a JIT, interpreter, etc.</div>
<div><br></div><div>3) People using LLVM+Clang(+LLD)?(+LLDB)? only as a C/C++/ObjC/ObjC++ toolchain (including the linker and debugger in that as necessary) for their development. They don't use any of the libraries, but do use very end-user tools like clang-format, clang-check, libclang.so (for their editor), etc.</div>
<div><br></div><div><br></div><div>The only people who need #1 to be supported by the *install* are people building LLVM projects in a stand-alone way from the core. There are several people at Apple that do this for Clang because xcode is happier with the project files that way. I think they could probably enable a default-off feature to get this.</div>
<div><br></div><div>While I would *like* for usecase #3 to go away (as #2 is a strict superset). I'm happy with the defaults assuming that #3 doesn't exist. However, I suspect as long as we produce static libraries for everything *and* statically link all the tools, #3 is a useful thing to provide.</div>
<div><br></div><div> </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>
<div class="gmail_extra"><br></div><div class="gmail_extra">Personally I want to distribute llc and opt, even if they bloat the package by 2x for now, but I could be talked out of it.  I like the idea of the usual -emit-llvm -S, opt, llc, pipelines being available out of the box.</div>
</div></blockquote><div><br></div><div>I do too. I see these as part of #2 above -- anyone actually working with the infrastructure in detail needs them. But if you're really just in this for a toolchain, you're probably fine with #3 not having them.</div>
<div> </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"><br></div><div class="gmail_extra">Longer term, I wanted to experiment with building something like bigLLVM.dll and bigclang.dll (names are bad, whatever) which exposes the minimal set of exports necessary to interface with the binaries in tools/.  This avoids most of the code bloat from static linking without paying for all the relocation and runtime overhead of our usual BUILD_SHARED_LIBS build.  Then the cost of distributing the LLVM tools would be smaller.  It might not be practical, given the tight coupling between clang IRgen and LLVM's C++ API.</div>
</div></blockquote><div><br></div><div>Yea, this makes sense. There has to be a way to factor this appropriately IMO. We need #2 to be totally practical for folks to be using by default. I'm very happy if the option for #3 goes away some day. =D</div>
</div></div></div>