llvm dev - Oct 2015 - The future of LLVM's C APIs: Notes and BoF.

(Moving this to llvm-dev)

On Friday, October 16, 2015, Justin Bogner <mail at justinbogner.com>
wrote:
> Some users of llvm-c want stable API interfaces into various parts of
> the LLVM infrasture, others want further ABI guarantees about this
> usage, and still others simply want a way to bind to LLVM through their
> language frontend’s existing FFI support for C.
>
> If we want to improve the situation for any of these users, we need to
> properly understand how these APIs are being used (or abused)
> today. Juergen and I will be hosting a BoF at the dev meeting where we
> can discuss what the requirements of a sustainable C API are, and how we
> can organize things in LLVM to support this.
>
> There's been a fair amount of discussion about this lately, and
it's
> pretty clear that the "hopefully stable bindings to whatever APIs
> somebody needed" approach isn't really good enough for anybody.
There
> are a couple of points that I think are fairly non-controversial, but
> will more or less drive the discussion at the BoF:
>
> 1. It isn't practical to keep a bindings API stable, unless the
>    underlying API is also stable.
>
> 2. Handrolling bindings as they're needed tends to leave conspicuous
>    gaps where some API is inaccessible for no good reason.
>
> So based on (1), we'll really want to create some purpose built APIs
> that we can keep stable for various tasks. What's needed here? People
> want to do things like building a pass manager, setting up a canned JIT
> config, and to some degree even emit IR. We'll discuss what's
practical
> and what people want, and hopefully strike a good balance.
>
> Similarly, (2) implies that if we really need a *full* bindings API
> we'll want to automate it. But what is a full bindings API? Who uses
it,
> and what do they want from it? If it's automated, should installing
LLVM
> install this API, or should we simply provide an easy way to generate
> it?
>
> In the end, I hope to have a good idea of what people are actually using
> these APIs for, and both to support stable API users less haphazardly
> and to make unstable API more thorough and/or easier to create.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151017/d6f69be1/attachment.html>