I think this hurts Clang layering and maintainability. At the moment, *within Clang*, it's very useful to have most of the CodeGen headers in lib/CodeGen rather than within include/clang/CodeGen, since that makes obvious and enforces the layering between CodeGen's private headers and the rest of Clang.
=> I'm opposed to this change. The CodeGen API is even more implementation details than the AST and Sema API. If you want to include clang's internal implementation details, go ahead, but I don't think we should break our own layering to support this. On Mon, Aug 25, 2014 at 3:04 PM, Reid Kleckner <[email protected]> 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 <[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 > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
