<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, 20 Jul 2015 at 12:49 Hal Finkel <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">----- Original Message -----<br>
> From: "Hayden Livingston" <<a href="mailto:halivingston@gmail.com" target="_blank">halivingston@gmail.com</a>><br>
> To: "Eric Christopher" <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>><br>
> Cc: "Chris Lattner" <<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>>, "Hal Finkel" <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>>, "LLVM Dev" <<a href="mailto:llvmdev@cs.uiuc.edu" target="_blank">llvmdev@cs.uiuc.edu</a>>, "Lang<br>
> Hames" <<a href="mailto:lhames@apple.com" target="_blank">lhames@apple.com</a>><br>
> Sent: Sunday, July 19, 2015 10:37:11 PM<br>
> Subject: Re: [LLVMdev] [RFC] Developer Policy for LLVM C API<br>
><br>
> While I understand the people committing to the primarily C++<br>
> codebase<br>
> of LLVM find it as additional burden, far more number of people enjoy<br>
> the benefits of an official LLVM C API support than are vocal here.<br>
><br>
> While Clang maybe the first-class LLVM citizen for the foreseeable<br>
> future, I can tell you LLVM is used in many more situations (I'm<br>
> talking about Rust, Go, Julia, DLang, etc.) than this alias realized.<br>
> I alone am using it interesting projects I hope to release sometime<br>
> this year and all of these projects rely on the comfort of the<br>
> "official" C API.<br>
<br>
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.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div>Andrew</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> I sympathize with the community that is not using them but having to<br>
> still maintain and fix bugs. To those of you (on this thread and<br>
> others) who are wanting to remove the C API from the project, please<br>
> tell the community what can be done to improve the situation. Do we<br>
> need bots? People writing tests?<br>
<br>
Regardless, we certainly need tests.<br>
<br>
><br>
> I would like to put my support behind discouraging the idea of<br>
> pushing<br>
> the bindings to a side project.<br>
<br>
Clang is a side project ;)<br>
<br>
 -Hal<br>
<br>
><br>
> On Sun, Jul 19, 2015 at 7:24 PM, Eric Christopher<br>
> <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>> wrote:<br>
> > Hi Chris,<br>
> ><br>
> > On Sun, Jul 19, 2015 at 9:16 AM Chris Lattner <<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>><br>
> > wrote:<br>
> >><br>
> >> On Jul 18, 2015, at 11:27 AM, Hal Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>> wrote:<br>
> >> >> I am strongly in favor of moving the bindings, C or otherwise,<br>
> >> >> to<br>
> >> >> another project.<br>
> >> ><br>
> >> > I agree. From my viewpoint we have two primary problems with the<br>
> >> > C API:<br>
> >> ><br>
> >> > 1. Many of the LLVM contributors don't use it, and thus, don't<br>
> >> > have a<br>
> >> > great understanding of how it can be most-usefully<br>
> >> > updated/improved, and<br>
> >> > what functionality needs to be exposed. We have most, but not<br>
> >> > all,<br>
> >> > transformations; many, but not all, IR features, etc.<br>
> >> ><br>
> >> > 2. We don't have a good set of tests for it, nor do we have a<br>
> >> > good set<br>
> >> > of tutorials/documentation for it. Our tutorials, specifically,<br>
> >> > are in C++,<br>
> >> > not in C. We could break the C API and we'd likely remain<br>
> >> > unaware for quite<br>
> >> > awhile.<br>
> >> ><br>
> >> > Putting it in a separate project will force those who have a<br>
> >> > stake in<br>
> >> > its existence to take the responsibility of moving it forward.<br>
> >> > Separate<br>
> >> > project, or not, however, we should have a better developer<br>
> >> > policy regarding<br>
> >> > the C API (and the other bindings) that fall under the LLVM<br>
> >> > umbrella.<br>
> >> > Specifically, we should outline what features need to be<br>
> >> > exposed, and we<br>
> >> > should actively maintain (and test for) full coverage of those<br>
> >> > features.<br>
> >><br>
> >> I don’t understand the motivation for this.  Is there tension<br>
> >> between<br>
> >> clients of the C API that would warrant having different<br>
> >> approaches/implementations?  Moving it out to a subproject to get<br>
> >> better<br>
> >> testing seems a bit silly.<br>
> >><br>
> >> Personally, unless there is a strong and compelling reason to do<br>
> >> so, I’d<br>
> >> prefer to keep a single set of C bindings to encourage<br>
> >> standardization and<br>
> >> avoid fragmenting the community.<br>
> >><br>
> ><br>
> >  So, I made this proposal for what I think is a pretty good reason.<br>
> >  There's<br>
> > an "unofficial" as Juergen said, policy that the C API is the<br>
> > stable API.<br>
> > There's nothing wrong with a stable C API, but that's what I'm<br>
> > proposing<br>
> > should move out of tree to where those that are most concerned with<br>
> > it can<br>
> > develop it and ensure that it remains stable for whatever<br>
> > guarantees they<br>
> > want.<br>
> ><br>
> > Some background here:<br>
> ><br>
> > Right now we definitely have this dichotomy between a "bindings" C<br>
> > API and a<br>
> > "stable" C API. The unofficial policy as I mentioned above is that<br>
> > there's<br>
> > one C API and that's the stable API. Over the last 3-5 years or so<br>
> > the<br>
> > "stable" C API has started growing in ways that encompass just<br>
> > about every<br>
> > class and API in llvm. We've occasionally denied bindings level API<br>
> > support<br>
> > because we knew the code in that area was going to change - but<br>
> > just imagine<br>
> > we'd let a few of them in, we wouldn't have been able to do the<br>
> > IR/Metadata<br>
> > split at all. As it is we technically broke the C API, just not in<br>
> > a way<br>
> > that any external user cared about.<br>
> ><br>
> > Back to the proposal:<br>
> ><br>
> > What I'm proposing is that we make the C API that exists in tree a<br>
> > bindings<br>
> > API that has the same stability guarantees as the C++ API. Honestly<br>
> > it'll<br>
> > probably much more stable, but at least then we won't have to worry<br>
> > or<br>
> > revert work because the C API was "too close to the machine" or<br>
> > rather the<br>
> > C++ code.  This means that someone that wants a stable C API can go<br>
> > off and<br>
> > develop one (tests and all) and we can possibly look at bringing it<br>
> > back<br>
> > into tree at some point in the future. For example, if someone<br>
> > comes up with<br>
> > a good "libjit" api then we can look at how the API design works<br>
> > and make<br>
> > sure it's general enough that it's not going to cause undue<br>
> > solidification<br>
> > of the existing APIs.<br>
> ><br>
> > Caveat: I'm not talking about the existing libclang or liblto<br>
> > libraries.<br>
> > Those seem to work and have a small enough API surface that they<br>
> > seem<br>
> > reasonable to support and we can move to a new API if they seem to<br>
> > be<br>
> > hindering development in the future.<br>
> ><br>
> > This help explain where I'm coming from here?<br>
> ><br>
> > Thanks!<br>
> ><br>
> > -eric<br>
> ><br>
> > _______________________________________________<br>
> > LLVM Developers mailing list<br>
> > <a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
> ><br>
><br>
<br>
--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div></div>