<div dir="ltr">On Sat, Aug 24, 2013 at 7:29 AM, Joerg Sonnenberger <span dir="ltr"><<a href="mailto:joerg@britannica.bec.de" target="_blank" class="cremed">joerg@britannica.bec.de</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Fri, Aug 23, 2013 at 10:15:41PM -0700, Chandler Carruth wrote:<br>
> On Fri, Aug 23, 2013 at 10:11 PM, Joerg Sonnenberger <<br>
> <a href="mailto:joerg@britannica.bec.de" class="cremed">joerg@britannica.bec.de</a>> wrote:<br>
><br>
> > On Fri, Aug 23, 2013 at 06:28:10PM -0000, Hans Wennborg wrote:<br>
> > > Author: hans<br>
> > > Date: Fri Aug 23 13:28:10 2013<br>
> > > New Revision: 189130<br>
> > ><br>
> > > URL: <a href="http://llvm.org/viewvc/llvm-project?rev=189130&view=rev" target="_blank" class="cremed">http://llvm.org/viewvc/llvm-project?rev=189130&view=rev</a><br>
> > > Log:<br>
> > > CMake: don't install tablegen<br>
> > ><br>
> > > Since it's an llvm-internal tool, we shouldn't install it.<br>
> ><br>
> > Is it really llvm-internal? The support for libOption makes me think<br>
> > it is not.<br>
> ><br>
><br>
> I don't think we can or should realistically try to support external users<br>
> of libOption... It's really a utility library for building drivers like<br>
> Clang and LLD, not something that we can reasonably support fully generic<br>
> use of it. Similarly for the tablegen libraries and a few others.<br>
<br>
</div>Sure, but the thing I am thinking about (mclinker) effectively falls<br>
into the same category.<br></blockquote><div><br></div><div>Then it can get at it in the same way, by referencing the build tree rather than the install tree.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The point I am trying to make is that lib/Option is a very valid use<br>
case of tablegen outside llvm itself. That's unlike most other functions<br>
of it.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
Joerg<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" class="cremed">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank" class="cremed">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div></div>