A patch to move codegen includes into public include

[Sean Silva]

On Mon, Aug 25, 2014 at 6:27 PM, Chandler Carruth <chandlerc at google.com>
wrote:

>
> On Mon, Aug 25, 2014 at 6:05 PM, Sean Silva <chisophugis at gmail.com> wrote:
>
>> Yes. It was in reply to a statement that seemed to suggest a "design
>> public API up front, then implement the whole thing" approach (not a
>> "incrementally approach our use cases, carefully considering the design of
>> the API at each step" approach). It seems like the "design API up front"
>> approach is the exception rather than the norm in LLVM-land, so it was
>> strange to see it being suggested as a preference.
>
>
> Sorry, I wasn't trying to preclude an incremental approach here.
>
> I'm saying design the API that you are adding, as you add it. That doesn't
> have to be the *entire* API or the final version of the API. Each increment
> should be designed with some care and thought behind it.
>
> The proposed patch is specifically not doing *any* design of the API or
> finding small increments at which the design makes sense.
>
>
A similar design approach occurs for all API's, be they "internal" or not,
as API cleanliness and usability is a boon for internal users as well as
external.

Actually, we must have been doing a pretty good job about the API design
from the fact that users have been able to hoist these headers into
include/ and get good mileage from them, to the point that the requested
change is simply to move them to include/.

I agree that just slopping clang/lib/CodeGen/*.h file into include/ is not
the right approach. However, I don't think there's an intrinsic reason to
expect that the API's are somehow unsuitable for public use exactly as they
stand now in lib/. I would prefer (modulo Richard's comment about not
exposing these without internal users), that as we get compelling use
cases, we bring up the necessary headers into include/ to satisfy them,
making any necessary incremental changes to better serve the use case.


-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140825/2d195ae5/attachment.html>