[LLVMdev] [RFC] Developer Policy for LLVM C API

[Eric Christopher]

On Mon, Jul 20, 2015 at 1:37 PM Juergen Ributzka <juergen at apple.com> wrote:

> Wow, this went of topic very quickly ;-)
>
>
It did. I am sorry about that :)


> As you know I am very interested in an stable API (C and/or C++) for LLVM,
> but maybe we should discuss this in a separate thread. Designing a good
> stable API from scratch will take some time and until that point I want to
> document our current “tribal knowledge”. I will post a patch as you
> suggested.
>
>
Thanks. Given the direction it's taken and the positive feedback I've
gotten on the existing C API we might want to document it as "in flux" :)

That said, here's how I see this happening if we were to go the direction
I'm proposing:

I think we should bite the bullet and say that the growth we've had in the
C API is past what we were originally promising and just call the existing
C API the "bindings" api. From there we can move the LTO headers to a new
directory (insert bikeshed) and say that the existing code in llvm-c isn't
stable.  We can then migrate the things we want to be stable into a new
directory with real stability guarantees. I'm seeing an API (possibly
versioned) with a much lower surface area here similar, possibly, to the
LTO stuff or libclang.

I totally believe that existing clients could break through this and I want
to minimize that as much as possible as it's our responsibility here. I
think, in general, we've been stable enough in the existing C API to keep
it going until we can define something that's actually stable that we can
migrate clients to though.

Thoughts?

-eric



> —Juergen
>
> On Jul 20, 2015, at 1:08 PM, Eric Christopher <echristo at gmail.com> wrote:
>
>
>> Part (most?) of the point of having a stable API is as a way of
>> decoupling the development processes of two separate projects (modulo
>> well-documented release-to-release updating). Requiring our users to add
>> tests in our tree doesn't really achieve much decoupling.
>>
>>
>> I’m not sure there is much “coupling” here. The point is that we expose a
>> C API that is supposed to be stable but is not well tested. And some part
>> of the C API is just a wrapper around the C++ and hasn’t really been
>> designed to be “stable” in time.
>> It seems also that we don’t really know what part of the C API really
>> needs to be stable and is important for the users, so I read Pete’s
>> proposal as “let’s collect the current use-cases and make them tests in
>> LLVM, so that we define what is part of the stable C API and so that we
>> won’t (inadvertently) break valid use cases".
>>
>>
> Yeah, this is just terrible though for all of the reasons I raised in my
> email and as you even say here "And some part of the C API is just a
> wrapper around the C++ and hasn’t really been designed to be “stable” in
> time."
>
>
>>
>> As of having this in-tree or out-of-tree, I’m not sure about that and
>> there is a trade-off.
>>
>>
> I'm regretting ever saying "out of tree" here as I don't think it's the
> main issue, rather the splitting of the "bindings" style of api that we see
> a lot of in the C API directory and the more solid ones that we see from
> libclang and liblto.
>
> -eric
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150720/31a454f0/attachment.html>