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

On Oct 17, 2015, at 12:14 AM, Justin Bogner via cfe-dev <cfe-dev at
lists.llvm.org> wrote:
> 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
<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:
> 1. It isn't practical to keep a bindings API stable, unless the
>   underlying API is also stable.
Yes, I agree with this.
> 2. 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!

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151022/8e12a51e/attachment-0001.html>