A patch to move codegen includes into public include

[DeadMG]

Hm, I rebuilt and ran tests with the patch applied. But then again, Clang
obviously has Clang's internals on the include path, so that was probably a
dumb test.

There are no renames, it was just a move.


On 25 August 2014 23:04, Reid Kleckner <rnk at google.com> wrote:

> 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/9f6316a2/attachment.html>