[LLVMdev] [RFC] Developer Policy for LLVM C API (original) (raw)

Philip Reames listmail at philipreames.com
Thu Jul 30 15:35:55 PDT 2015

It's sounds like we've reached two rough conclusions:

  1. We need both a stable and a non-stable fully featured C API. It's a somewhat open question whether both or either should be part of the main tree.
  2. Everyone seemed okay with the proposed deprecation policy for the stable API.

Given this, I would propose we designate the existing C API as the "hopefully stable, but subject to future clean up per policy..." Update the documentation to note that LLVM does not currently have a fully featured C API. Update the docs to reflect the deprecation policy for the existing C API.

We can then start discussing how we should create the fully featured API. I'd lean towards a tool like Swig, but we could also do it purely on demand. For example, I could add some shims for the experimental GC support without committing to supporting the current APIs long term.

Philip

On 07/30/2015 01:47 PM, Reid Kleckner wrote:

On Thu, Jul 30, 2015 at 1:04 PM, Eric Christopher <echristo at gmail.com_ _<mailto: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.

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/20150730/d7b08975/attachment.html>

More information about the llvm-dev mailing list