<div dir="ltr"><div>I think we should do this. At this point we have two known out-of-tree clients trying to talk to lib/CodeGen, and I expect there will be more. Julia has an experimental C++ API interop, and I don't know what your project is, but I know of it. :) LLDB wanted to in the past, they may try again. Basically anyone who wants interop with rich C++ interfaces can use some of lib/CodeGen, even if it isn't currently structured for their needs.</div>
<div><br></div>I'm not sure how this patch is applicable in it's current state, because I don't think it captures the actual renames and doesn't actually fix CodeGenFunction.h & co to not reference lib/CodeGen internal headers.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 25, 2014 at 11:36 AM, DeadMG <span dir="ltr"><<a href="mailto:wolfeinstein@gmail.com" target="_blank">wolfeinstein@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">This is certainly not all of it. These are just the headers I found 
myself to have used so far when grepping my codebase. There are others I'll probably need later. Developing a 
public interface requires access to the internals to implement them on 
top of, and having them be private instead of just not officially 
supported is a real problem for me when trying to develop that interface
 on top.<br>
<br>Frankly, we don't really need a lib/ABI. The existing interfaces 
are, in the majority of cases, really enough. They just need to be a 
smidge more abstract and support direct IR interoperation, which won't 
require many changes. It's just an issue of being able to practically 
work in this area. Having to build Clang from source on every machine is
 a fairly large practical impediment for me.</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On 25 August 2014 16:11, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I can see why you need some of codegen exposed, but do you really need<br>
all of it? Maybe we should have a lib/ABI that is used by lib/CodeGen?<br>
<div><div><br>
On 23 August 2014 17:06, DeadMG <<a href="mailto:wolfeinstein@gmail.com" target="_blank">wolfeinstein@gmail.com</a>> wrote:<br>
> Dear all,<br>
><br>
> I have attached a quick patch, which simply moves some previously-internal<br>
> CodeGen headers into the public include, based on r216273.<br>
><br>
> Placing these headers in the public include will drastically simplify the<br>
> development cycle for the layer on top of CodeGen that I discussed on<br>
> cfe-dev, targetted for 3.6. Developing that layer on top of 3.4 was a pain<br>
> for me as requiring all my users and developers to build LLVM and Clang from<br>
> source was time-consuming and fiddly.<br>
><br>
> Ideally, this would be merged into 3.5 (although I believe that ship has<br>
> sailed even for such simple patches) or a hypothetical 3.5.1. As this only<br>
> moves a few headers from one location to another, extensive testing<br>
> shouldn't be required, but just for the record, I tested on Ubuntu 14.04<br>
> with no additional failures.<br>
><br>
</div></div>> _______________________________________________<br>
> cfe-commits mailing list<br>
> <a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
><br>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
<br></blockquote></div><br></div>