[PATCH] CMake: add LLVM_INSTALL_DEV_FILES variable

[Hans Wennborg]

On Mon, Aug 19, 2013 at 4:10 PM, Hans Wennborg <hans at chromium.org> wrote:
> 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 :)

OK, following up on our offline talk, we want a single cmake flag to
control which of the three use cases to hit:

- #2: (default), the stuff a user of llvm as a library would use
- #3: toolchain-only, i.e. clang, lld, binutils-like tools
- #1: "everything", what we have today.

I'll see if I can turn this into a patch.

 - Hans