[PATCH] CMake: add LLVM_INSTALL_DEV_FILES variable

Chandler Carruth chandlerc at google.com
Mon Aug 19 15:52:38 PDT 2013


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?

That's why I'm pushing for this. I think as we start to have increased
usage of the install action by users, this will increasingly be the right
set to install. As it stands, distributions are having to pull these
overly-general binaries out of the install. =/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130819/82f4843f/attachment.html>


More information about the llvm-commits mailing list