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.
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. On Mon, Aug 25, 2014 at 11:36 AM, DeadMG <[email protected]> wrote: > 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. > > 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. > > > On 25 August 2014 16:11, Rafael Espíndola <[email protected]> > wrote: > >> I can see why you need some of codegen exposed, but do you really need >> all of it? Maybe we should have a lib/ABI that is used by lib/CodeGen? >> >> On 23 August 2014 17:06, DeadMG <[email protected]> wrote: >> > Dear all, >> > >> > I have attached a quick patch, which simply moves some >> previously-internal >> > CodeGen headers into the public include, based on r216273. >> > >> > Placing these headers in the public include will drastically simplify >> the >> > development cycle for the layer on top of CodeGen that I discussed on >> > cfe-dev, targetted for 3.6. Developing that layer on top of 3.4 was a >> pain >> > for me as requiring all my users and developers to build LLVM and Clang >> from >> > source was time-consuming and fiddly. >> > >> > Ideally, this would be merged into 3.5 (although I believe that ship has >> > sailed even for such simple patches) or a hypothetical 3.5.1. As this >> only >> > moves a few headers from one location to another, extensive testing >> > shouldn't be required, but just for the record, I tested on Ubuntu 14.04 >> > with no additional failures. >> > >> > _______________________________________________ >> > cfe-commits mailing list >> > [email protected] >> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >> > >> > > > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
