<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sun, Jul 19, 2015 at 8:37 PM Hayden Livingston <<a href="mailto:halivingston@gmail.com">halivingston@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">While I understand the people committing to the primarily C++ 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></blockquote><div><br></div><div>I can assure you I'm more than well aware of all of these projects and more.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I would like to put my support behind discouraging the idea of pushing<br>
the bindings to a side project.<br>
<br></blockquote><div><br></div><div>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.</div><div><br></div><div>-eric</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sun, Jul 19, 2015 at 7:24 PM, Eric Christopher <<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>> 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, to<br>
>> >> another project.<br>
>> ><br>
>> > I agree. From my viewpoint we have two primary problems with the C API:<br>
>> ><br>
>> > 1. Many of the LLVM contributors don't use it, and thus, don't have a<br>
>> > great understanding of how it can be most-usefully updated/improved, and<br>
>> > what functionality needs to be exposed. We have most, but not 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 good set<br>
>> > of tutorials/documentation for it. Our tutorials, specifically, are in C++,<br>
>> > not in C. We could break the C API and we'd likely remain unaware for quite<br>
>> > awhile.<br>
>> ><br>
>> > Putting it in a separate project will force those who have a stake in<br>
>> > its existence to take the responsibility of moving it forward. Separate<br>
>> > project, or not, however, we should have a better developer policy regarding<br>
>> > the C API (and the other bindings) that fall under the LLVM umbrella.<br>
>> > Specifically, we should outline what features need to be exposed, and we<br>
>> > should actively maintain (and test for) full coverage of those features.<br>
>><br>
>> I don’t understand the motivation for this.  Is there tension between<br>
>> clients of the C API that would warrant having different<br>
>> approaches/implementations?  Moving it out to a subproject to get better<br>
>> testing seems a bit silly.<br>
>><br>
>> Personally, unless there is a strong and compelling reason to do so, I’d<br>
>> prefer to keep a single set of C bindings to encourage standardization and<br>
>> avoid fragmenting the community.<br>
>><br>
><br>
>  So, I made this proposal for what I think is a pretty good reason. There's<br>
> an "unofficial" as Juergen said, policy that the C API is the stable API.<br>
> There's nothing wrong with a stable C API, but that's what I'm proposing<br>
> should move out of tree to where those that are most concerned with it can<br>
> develop it and ensure that it remains stable for whatever guarantees they<br>
> want.<br>
><br>
> Some background here:<br>
><br>
> Right now we definitely have this dichotomy between a "bindings" C API and a<br>
> "stable" C API. The unofficial policy as I mentioned above is that there's<br>
> one C API and that's the stable API. Over the last 3-5 years or so the<br>
> "stable" C API has started growing in ways that encompass just about every<br>
> class and API in llvm. We've occasionally denied bindings level API support<br>
> because we knew the code in that area was going to change - but just imagine<br>
> we'd let a few of them in, we wouldn't have been able to do the IR/Metadata<br>
> split at all. As it is we technically broke the C API, just not in 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 bindings<br>
> API that has the same stability guarantees as the C++ API. Honestly it'll<br>
> probably much more stable, but at least then we won't have to worry or<br>
> revert work because the C API was "too close to the machine" or rather the<br>
> C++ code.  This means that someone that wants a stable C API can go off and<br>
> develop one (tests and all) and we can possibly look at bringing it back<br>
> into tree at some point in the future. For example, if someone comes up with<br>
> a good "libjit" api then we can look at how the API design works and make<br>
> sure it's general enough that it's not going to cause undue solidification<br>
> of the existing APIs.<br>
><br>
> Caveat: I'm not talking about the existing libclang or liblto libraries.<br>
> Those seem to work and have a small enough API surface that they seem<br>
> reasonable to support and we can move to a new API if they seem to 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>
</blockquote></div></div>