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

[Reid Kleckner]

On Thu, Jul 30, 2015 at 1:04 PM, Eric Christopher <echristo at gmail.com>
wrote:

> I think the idea of having a (hopefully not too) fluid C API that can
> encompass everything people want to be able to do in the language of their
> choice and calls into LLVM to do work sounds like a great idea. I think it
> would be useful to expand the number of people who are able to do research
> and development with LLVM without having to reinvent LLVM. That said, this
> is directly at odds with our desire to have a stable C API that can be
> supported long term (as you said at the end of the email). I.e. where do we
> draw the line on what can or should be added to the C API? What if the
> people that want the functionality are willing to deal with it being
> (occasionally) unstable?
>

Yeah, splitting the concerns of API completeness and API stability seems
like a good idea. Right now we have clients like llgo that want to generate
new debug info, and are perfectly happy to keep up to date with changes.
They need a complete API, not a stable API, and our insistence on a stable
C API has actually gotten in the way here.


> I don't agree with you that no one will take the time to design a well
> thought out C API. We've managed to get a lot of real world experience
> lately at both how these things will be used, and how we'll maintain such a
> thing. I think Juergen and others are a good group to come up with an
> answer to our engineering challenge.
>

Sure, if people are planning to design a stable API that leave LLVM with
more flexibility, then I'm all in favor of switching over to it. So far I
haven't heard any new suggestions. I think any such design would probably
be write-only, and revolve around sharing the bitcode auto-upgrade logic.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150730/95de5a69/attachment.html>