A patch to move codegen includes into public include

[Reid Kleckner]

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 <wolfeinstein at gmail.com> 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 <rafael.espindola at gmail.com>
> 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 <wolfeinstein at gmail.com> 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
>> > cfe-commits at cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>> >
>>
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140825/518d2e91/attachment.html>