[PATCH] CMake: add LLVM_INSTALL_DEV_FILES variable

[Michael Gottesman]

This sounds great = ).

Michael

On Aug 19, 2013, at 4:26 PM, Hans Wennborg <hans at chromium.org> wrote:

> 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
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130819/267ec921/attachment.html>