<div dir="ltr"><div class="gmail_extra">I think you understood me.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 21, 2013 at 2:58 AM, Michael Gottesman <span dir="ltr"><<a href="mailto:mgottesman@apple.com" target="_blank" class="cremed">mgottesman@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>At the same time I think that we should provide some nobs under the hood that a developer can use to customize said options. Specifically why not introduce something along the lines of LLVM_INSTALL_TYPE that beneath the hood triggers other CMake variables which control what is actually installed or not.</div>
</blockquote><div><br></div><div>Because I actively want fewer knobs and controls. They just bitrot and remain undocumented. I very much think that this is way more complexity than we have actual use cases for today, and I think we should pick the solution of minimal complexity to address the use cases we have today, and no more. If we come up with a new use case tomorrow, this is not a place where re-doing the engineering will realistically cost us any appreciable amount.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div><div>Then as a user I can get the configuration profile aspect that will make my life easier, but as a developer if I want my roots a specific way, I can get what I want since I can override the variables. To give you an example, for our apple-clang roots, we want .dylibs (i.e. for libLTO.dylib), but not static archives. That is not a use-case which fits into the provided schemas as laid out in this email thread, but is supported by auto tools.</div>
</blockquote><div><br></div><div>OK, here is a concrete use case.</div><div><br></div><div>First, to better understand, I need to know *which* shared libraries you want in this set. Only those with stable interfaces? That's libLTO and libclang AFAIK. A long time ago, there was a nice stable interface to LLVM proper, but I don't think that's been properly maintained the way libLTO and libclang have been over the years.</div>
<div><br></div><div>If those are all you want, I would expect you to install the 'toolchain-only' thing above. It should include any libraries that drive parts of the compilation pipeline, which these definitely do. In addition, it would include the Gold plugin on Linux for similar reasons.</div>
<div><br></div><div><br></div><div>If you want to build *all* of the LLVM libraries as shared libraries and install them, I think you want the libraries-and-toolchain (to use your names, not trying to suggest those are the right or wrong names), and to toggle the boolean switch to enable building shared libraries. We could fold this boolean state into the others, but it actually seems reasonably orthogonal: one controls how much gets installed, the other controls whether we force building shared libraries.</div>
<div><br></div><div><br></div><div>But maybe you want some other set?</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div>
<div>My overall feeling is that if we truly want the cmake toolchain to be a drop in replacement (or almost drop in) replacement for the auto tools toolchain, then we need to ensure that we hit all the use cases that the auto tools toolchain does. Flexibility here will help.</div>
</blockquote><div><br></div><div>I don't think flexibility alone will help. I think we need concrete use cases, and then to design a system that addresses those needs. Let's focus there.</div></div></div></div>