[PATCH] CMake: add LLVM_INSTALL_DEV_FILES variable

[Hans Wennborg]

On Fri, Aug 16, 2013 at 5:07 PM, Chandler Carruth <chandlerc at google.com> wrote:
> On Fri, Aug 16, 2013 at 4:57 PM, Reid Kleckner <rnk at google.com> wrote:
>>
>> On Fri, Aug 16, 2013 at 4:22 PM, Chandler Carruth <chandlerc at google.com>
> Yea, sorry, didn't mean to imply that it would change the defaults. =] I'm
> actually *asking* for a change to the defaults.
>
>>
>> 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.
>
>
> I do think so. I think there are three classes of users:
>
> 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).

This is what "make install" provides for today.

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

So this is #1 minus tablegen, lit and build system files?

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

This is what you get if you set LLVM_INSTALL_DEV_FILES=OFF from my
patch, and use the existing LLVM_BUILD_TOOLS=OFF (disables building
llc, opt, etc.).

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

Are you saying that you'd like #2 to be the default instead of #1?

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

I'm not following here. Why do you want #3 to go away, isn't this the
typical use case for the end-user who just wants a toolchain? #3 is
the case I'm trying to enable :)


 - Hans