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.
I actually almost entirely disagree with the above. 
I believe that “somewhat stable bindings to whatever APIs people needed” IS good enough for users of these bindings, and I still would like to see that as the official policy (as per the code review I sent out before, proposing that, http://reviews.llvm.org/D12685).
Yes, the current situation sucks, but as I see it, the major problem is that additional bindings that people want, and attempt to add, get VETOED, because of the fear of imposing an impossible future compatibility guarantee.
The solution is to stop imposing an impossible compatibility guarantee. I strongly believe that’s literally the ONLY change that needs to be made to fix the current situation.
Again, while we’re causing this self-inflicted wound: what do users actually gain from it? Basically nothing. They still need to use the C++ API anyways, so the stablity provided is illusory. It’s essentially impossible to depend on the theoretical 100% ABI/API guarantee today.
There
are a couple of points that I think are fairly non-controversial, but
will more or less drive the discussion at the BoF:
- It isn’t practical to keep a bindings API stable, unless the
underlying API is also stable.
Yes, I agree with this.
- Handrolling bindings as they’re needed tends to leave conspicuous
gaps where some API is inaccessible for no good reason.
I disagree on the main cause of the gaps. Once we fix the compatibility policy, APIs can start being added again by interested parties to keep pace with additions to the LLVM C++ API (as happened in the earlier days of the project, before we hit this logjam!).
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.
I think this is basically a diversion from the issue at hand.
Firstly, I don’t believe there is a real need for inventing a brand new, super-restricted (necessarily! because if it was fully general it couldn’t be stable!) set of stable APIs. Even if there is a real need – which has NOT been demonstrated – someone will have to do that work. I’ve seen nobody volunteer to do that. I find this discussion of a yet-to-be-invented-actually-supportably-stable API a diversion from what to actually do, RIGHT NOW, to unblock proper maintenance for our EXISTING API.
Maybe someone will want to come up with a new set of APIs and a way to build a llvm shared library with a stable so-version, someday. Maybe they won’t. If they do in the future – that’s fine. Let’s have the discussion then. But in the meantime, I’d really like the existing APIs to start having a sane maintenance policy.
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?
I disagree with this as well. I think the quality of the APIs that come out of auto-generated bindings are typically below par, and that the LLVM-C APIs are actually overall well designed, and, before a few years ago, covered much of what people wanted to do. I do not think they should be discarded or deprecated. Furthermore, these auto-generated bindings are, again, non-existent – nobody has yet actually proposed what these would look like or worked on creating such a thing.
Again, the problem I see is that people are being effectively blocked from adding APIs to the LLVM-C bindings right now – people ARE volunteering to do that work but can not!