[PATCH] CMake: add LLVM_INSTALL_DEV_FILES variable

[Chandler Carruth]

On Fri, Aug 16, 2013 at 6:45 PM, Hans Wennborg <hans at chromium.org> wrote:

> On Fri, Aug 16, 2013 at 5:07 PM, Chandler Carruth <chandlerc at google.com>
> wrote:
> > 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
> >
> > 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).
>
> This is what "make install" provides for today.
>
> > 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.
>
> So this is #1 minus tablegen, lit and build system files?
>

Yes, and some other stuff (FileCheck?)


>
> > 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.


>
> > 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.


> > 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.
>
> I'm not following here. Why do you want #3 to go away, isn't this the
> typical use case for the end-user who just wants a toolchain? #3 is
> the case I'm trying to enable :)
>

Sorry, my "like" here was "in a beautiful ideal world where I get to ignore
the reality of where we are today". ;] Essentially, it would be nice (in an
idealistic sense) if all of the users of Clang/LLVM were interested in
using the *libraries* in addition to the basic toolchain when appropriate.

But the reality is that most folks using these things today are really
interested in C++ compiler, and we should provide a quick and easy way to
get one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130819/b2c43431/attachment.html>