A patch to move codegen includes into public include

DeadMG wolfeinstein at gmail.com
Mon Aug 25 11:36:09 PDT 2014


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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140825/6f5c9f2d/attachment.html>


More information about the cfe-commits mailing list