[PATCH] CMake: add LLVM_INSTALL_DEV_FILES variable

[Chandler Carruth]

On Fri, Aug 16, 2013 at 4:57 PM, Reid Kleckner <rnk at google.com> wrote:

> On Fri, Aug 16, 2013 at 4:22 PM, Chandler Carruth <chandlerc at google.com>
>  wrote:
>
>>
>> On Fri, Aug 16, 2013 at 3:48 PM, Hans Wennborg <hans at chromium.org> wrote:
>>
>>>   Change option name to LLVM_INSTALL_DEV_FILES. Also move cmake files
>>> and llvm-lit under this flag.
>>>
>>>   (Not changing the code review title to hopefully keep this in the same
>>> email thread.)
>>>
>>
>> Er, no?
>>
>> So, first note that this changes users of 'make install' in addition to
>> users of cpack.
>>
>> There are two layers of this:
>>
>> 1) install development tools / resources useful for developing other
>> *LLVM* projects (tblgen, etc)
>>
>> 2) install *anything* but executable binaries.
>>
>> I think these should be different. I think #1 should be default-off and
>> turned on for users of the stand-alone Clang cmake build. It should be
>> called something about "development".
>>
>> I think #2 should be default-on, because many many users of LLVM
>> specifically want the core libraries. I think the best way is to negate the
>> flag: make it INSTALL_TOOLCHAIN_BINARIES_ONLY or something, and when
>> enabled, you only get the binaries used as part of a toolchain
>> (llvm-{ar,nm,dwarfdump,...}, clang, clang-format, etc., but not opt or llc.
>>
>
> First, I just want to make it clear that this patch makes not default
> behavior change to 'make install' or anything else.  The headers, core
> libs, etc, are all on by default.
>

Yea, sorry, didn't mean to imply that it would change the defaults. =] I'm
actually *asking* for a change to the defaults.


> Do you think it's worth adding another option to separate "only install
> toolchain binaries" from "don't install development resources"?  If we can
> get by with fewer options, that seems better.
>

I do think so. I think there are three classes of users:

1) People working directly on LLVM or LLVM projects (LLD, Clang, something
else that directly shares the development infrastructure like build
systems, tablegen, and lit).

2) People using LLVM, both as a library and potentially the command line
tools and toolchain, to build other pieces of software. This would include
users of LLVM inside of a JIT, interpreter, etc.

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.


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.

While I would *like* for usecase #3 to go away (as #2 is a strict
superset). I'm happy with the defaults assuming that #3 doesn't exist.
However, I suspect as long as we produce static libraries for everything
*and* statically link all the tools, #3 is a useful thing to provide.



>
> Personally I want to distribute llc and opt, even if they bloat the
> package by 2x for now, but I could be talked out of it.  I like the idea of
> the usual -emit-llvm -S, opt, llc, pipelines being available out of the box.
>

I do too. I see these as part of #2 above -- anyone actually working with
the infrastructure in detail needs them. But if you're really just in this
for a toolchain, you're probably fine with #3 not having them.


>
> Longer term, I wanted to experiment with building something like
> bigLLVM.dll and bigclang.dll (names are bad, whatever) which exposes the
> minimal set of exports necessary to interface with the binaries in tools/.
>  This avoids most of the code bloat from static linking without paying for
> all the relocation and runtime overhead of our usual BUILD_SHARED_LIBS
> build.  Then the cost of distributing the LLVM tools would be smaller.  It
> might not be practical, given the tight coupling between clang IRgen and
> LLVM's C++ API.
>

Yea, this makes sense. There has to be a way to factor this appropriately
IMO. We need #2 to be totally practical for folks to be using by default.
I'm very happy if the option for #3 goes away some day. =D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130816/14c210d3/attachment.html>