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