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

Sun Jul 19 20:44:38 PDT 2015

On Sun, Jul 19, 2015 at 8:37 PM Hayden Livingston <halivingston at gmail.com>
wrote:

> While I understand the people committing to the primarily C++ codebase
> of LLVM find it as additional burden, far more number of people enjoy
> the benefits of an official LLVM C API support than are vocal here.
>
> While Clang maybe the first-class LLVM citizen for the foreseeable
> future, I can tell you LLVM is used in many more situations (I'm
> talking about Rust, Go, Julia, DLang, etc.) than this alias realized.
> I alone am using it interesting projects I hope to release sometime
> this year and all of these projects rely on the comfort of the
> "official" C API.
>
>
I can assure you I'm more than well aware of all of these projects and more.

> I sympathize with the community that is not using them but having to
> still maintain and fix bugs. To those of you (on this thread and
> others) who are wanting to remove the C API from the project, please
> tell the community what can be done to improve the situation. Do we
> need bots? People writing tests?
>
>
I want to not have to hamstring the progress of the project in order to
maintain a stable API across the entire project that I don't have to do
with the C++ API.

> I would like to put my support behind discouraging the idea of pushing
> the bindings to a side project.
>
>
I don't think you understood my email very well. "bindings" I'm fine with
keeping as part of project, just with the same stability guarantees as any
other part of the code base. A "stable" C API that "must not break", not so
much.

-eric

> On Sun, Jul 19, 2015 at 7:24 PM, Eric Christopher <echristo at gmail.com>
> wrote:
> > 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
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150720/b7842ebf/attachment.html>