[PATCH] CMake: add LLVM_INSTALL_DEV_FILES variable

[Chandler Carruth]

I think you understood me.

On Wed, Aug 21, 2013 at 2:58 AM, Michael Gottesman <mgottesman at apple.com>wrote:

> 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.
>

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.


>
> 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.
>

OK, here is a concrete use case.

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.

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.


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.


But maybe you want some other set?



> 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.
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130821/627620c0/attachment.html>