[PATCH] CMake: add LLVM_INSTALL_DEV_FILES variable

Wed Aug 21 02:58:14 PDT 2013

I was thinking about this a little bit more. I like the tri-configuration option, but I think that it might be constrictive on developers if we don’t do it right.

First, let me make sure I am understanding you correctly Chandler (just to be careful = ]). I feel that really what you are describing is some sort of notion of a configuration profile where you can enable/disable a bunch of options at once. Thus a user could go:

	cmake -G Ninja -DLLVM_INSTALL_TYPE=all

and get everything or,

	cmake -G Ninja -DLLVM_INSTALL_TYPE=toolchain-only

to get the compiler toolchain or:

	cmake -G Ninja -DLLVM_INSTALL_TYPE=libraries-toolchain

to get the libraries/compiler toolchain. There is a well defined use case here that I think will provide a lot of good for users.

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.

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.

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.

Waiting to hear your thoughts,
Michael

On Aug 19, 2013, at 11:54 PM, Michael Gottesman <mgottesman at apple.com> wrote:

> 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
> 
> _______________________________________________
> 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/20130821/f530fe75/attachment.html>