[LLVMdev] [RFC] Developer Policy for LLVM C API

[Eric Christopher]

Hi Chris,

On Sun, Jul 19, 2015 at 9:16 AM Chris Lattner <clattner at apple.com> wrote:

> On Jul 18, 2015, at 11:27 AM, Hal Finkel <hfinkel at anl.gov> wrote:
> >> I am strongly in favor of moving the bindings, C or otherwise, to
> >> another project.
> >
> > I agree. From my viewpoint we have two primary problems with the C API:
> >
> > 1. Many of the LLVM contributors don't use it, and thus, don't have a
> great understanding of how it can be most-usefully updated/improved, and
> what functionality needs to be exposed. We have most, but not all,
> transformations; many, but not all, IR features, etc.
> >
> > 2. We don't have a good set of tests for it, nor do we have a good set
> of tutorials/documentation for it. Our tutorials, specifically, are in C++,
> not in C. We could break the C API and we'd likely remain unaware for quite
> awhile.
> >
> > Putting it in a separate project will force those who have a stake in
> its existence to take the responsibility of moving it forward. Separate
> project, or not, however, we should have a better developer policy
> regarding the C API (and the other bindings) that fall under the LLVM
> umbrella. Specifically, we should outline what features need to be exposed,
> and we should actively maintain (and test for) full coverage of those
> features.
>
> I don’t understand the motivation for this.  Is there tension between
> clients of the C API that would warrant having different
> approaches/implementations?  Moving it out to a subproject to get better
> testing seems a bit silly.
>
> Personally, unless there is a strong and compelling reason to do so, I’d
> prefer to keep a single set of C bindings to encourage standardization and
> avoid fragmenting the community.
>
>
 So, I made this proposal for what I think is a pretty good reason. There's
an "unofficial" as Juergen said, policy that the C API is the stable API.
There's nothing wrong with a stable C API, but that's what I'm proposing
should move out of tree to where those that are most concerned with it can
develop it and ensure that it remains stable for whatever guarantees they
want.

Some background here:

Right now we definitely have this dichotomy between a "bindings" C API and
a "stable" C API. The unofficial policy as I mentioned above is that
there's one C API and that's the stable API. Over the last 3-5 years or so
the "stable" C API has started growing in ways that encompass just about
every class and API in llvm. We've occasionally denied bindings level API
support because we knew the code in that area was going to change - but
just imagine we'd let a few of them in, we wouldn't have been able to do
the IR/Metadata split at all. As it is we technically broke the C API, just
not in a way that any external user cared about.

Back to the proposal:

What I'm proposing is that we make the C API that exists in tree a bindings
API that has the same stability guarantees as the C++ API. Honestly it'll
probably much more stable, but at least then we won't have to worry or
revert work because the C API was "too close to the machine" or rather the
C++ code.  This means that someone that wants a stable C API can go off and
develop one (tests and all) and we can possibly look at bringing it back
into tree at some point in the future. For example, if someone comes up
with a good "libjit" api then we can look at how the API design works and
make sure it's general enough that it's not going to cause undue
solidification of the existing APIs.

Caveat: I'm not talking about the existing libclang or liblto libraries.
Those seem to work and have a small enough API surface that they seem
reasonable to support and we can move to a new API if they seem to be
hindering development in the future.

This help explain where I'm coming from here?

Thanks!

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150720/aff08fa7/attachment.html>