[llvm] r189130 - CMake: don't install tablegen

Chandler Carruth chandlerc at google.com
Sat Aug 24 17:02:13 PDT 2013


On Sat, Aug 24, 2013 at 7:29 AM, Joerg Sonnenberger <joerg at britannica.bec.de
> wrote:

> On Fri, Aug 23, 2013 at 10:15:41PM -0700, Chandler Carruth wrote:
> > On Fri, Aug 23, 2013 at 10:11 PM, Joerg Sonnenberger <
> > joerg at britannica.bec.de> wrote:
> >
> > > On Fri, Aug 23, 2013 at 06:28:10PM -0000, Hans Wennborg wrote:
> > > > Author: hans
> > > > Date: Fri Aug 23 13:28:10 2013
> > > > New Revision: 189130
> > > >
> > > > URL: http://llvm.org/viewvc/llvm-project?rev=189130&view=rev
> > > > Log:
> > > > CMake: don't install tablegen
> > > >
> > > > Since it's an llvm-internal tool, we shouldn't install it.
> > >
> > > Is it really llvm-internal? The support for libOption makes me think
> > > it is not.
> > >
> >
> > I don't think we can or should realistically try to support external
> users
> > of libOption... It's really a utility library for building drivers like
> > Clang and LLD, not something that we can reasonably support fully generic
> > use of it. Similarly for the tablegen libraries and a few others.
>
> Sure, but the thing I am thinking about (mclinker) effectively falls
> into the same category.
>

Then it can get at it in the same way, by referencing the build tree rather
than the install tree.


> The point I am trying to make is that lib/Option is a very valid use
> case of tablegen outside llvm itself. That's unlike most other functions
> of it.
>

If we want lib/Option to be a well supported library for external
customers, then we should build a dedicated tblgen binary *just* for
generating code necessary to use that library and install it.

My working theory is that there aren't really interesting needs for this
library to be in the set of those we support for external libraries. This
in contrast (for example) to libSupport. While libSupport is largely an
internal thing, we need it to be available to customers so that they can
use its types when crossing interface boundaries with LLVM's libraries. If
MCLinker is the only use case we have for libOption, I don't find it
particularly compelling.


>
> Joerg
> _______________________________________________
> 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/20130824/879b980e/attachment.html>


More information about the llvm-commits mailing list