[PATCH] CMake: add LLVM_INSTALL_DEV_FILES variable

[Hans Wennborg]

On Mon, Aug 19, 2013 at 3:52 PM, Chandler Carruth <chandlerc at google.com> wrote:
>
> On Mon, Aug 19, 2013 at 3:50 PM, Reid Kleckner <rnk at google.com> wrote:
>>
>> On Mon, Aug 19, 2013 at 3:20 PM, Chandler Carruth <chandlerc at google.com>
>> wrote:
>>>
>>> On Fri, Aug 16, 2013 at 6:45 PM, Hans Wennborg <hans at chromium.org> wrote:
>>>>
>>>> > 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.).
>>>
>>>
>>> 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.
>>
>>
>> I was pushing back against more options.  Less options means a simpler
>> configuration matrix.
>>
>>>>
>>>> > 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?
>>>
>>>
>>> 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.
>>
>>
>> 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.
>
>
> 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?

I agree that enabling #2 would be useful. The way we're basically just
copying all the build artifacts to the installation dir is not very
nice for an end user.

I think Reid has a point that #1 and #2 are pretty close though.

The difference between #3 (i.e. basically shipping just clang) and
what we currently have is huge, as in hundreds of megs libraries and
headers. I would really like to start with addressing this case :)

 - Hans