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

Sun Jul 19 22:16:34 PDT 2015

On Mon, 20 Jul 2015 at 12:49 Hal Finkel <hfinkel at anl.gov> wrote:

> ----- Original Message -----
> > From: "Hayden Livingston" <halivingston at gmail.com>
> > To: "Eric Christopher" <echristo at gmail.com>
> > Cc: "Chris Lattner" <clattner at apple.com>, "Hal Finkel" <hfinkel at anl.gov>,
> "LLVM Dev" <llvmdev at cs.uiuc.edu>, "Lang
> > Hames" <lhames at apple.com>
> > Sent: Sunday, July 19, 2015 10:37:11 PM
> > Subject: Re: [LLVMdev] [RFC] Developer Policy for LLVM C API
> >
> > 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.
>
> Do you require long-term cross-release ABI and/or API stability from the C
> API that you're using? Do these other projects? FWIW, many of us (most I'd
> guess) are well aware of Rust, Go, Julia, etc. and are excited to see them.
>

FWIW, neither the Go bindings nor llgo require that. The Go bindings API
itself is not stable; there's not a lot of change, but it does happen.
Also, the Go bindings exposes bits of the C++ API (DIBuilder) that are not
available through the C API.

Cheers,
Andrew

>
> > 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?
>
> Regardless, we certainly need tests.
>
> >
> > I would like to put my support behind discouraging the idea of
> > pushing
> > the bindings to a side project.
>
> Clang is a side project ;)
>
>  -Hal
>
> >
> > 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
> > >
> >
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
>
> _______________________________________________
> 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/0154a234/attachment.html>