[PATCH] CMake: add LLVM_INSTALL_DEV_FILES variable

Reid Kleckner rnk at google.com
Fri Aug 16 16:57:00 PDT 2013


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.

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.

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.

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.

If that falls through, then yeah, we can sweep llc etc under the umbrella
of dev files.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130816/ece8d8ec/attachment.html>


More information about the llvm-commits mailing list