<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sun, Jul 19, 2015 at 9:55 PM Chris Lattner <<a href="mailto:clattner@apple.com">clattner@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">On Jul 19, 2015, at 7:24 PM, Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>> wrote:</div><div style="word-wrap:break-word"><div><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote"><div>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.</div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>I don’t get it :-)</div></div></div><div style="word-wrap:break-word"><div><div><br></div><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote"><div>Some background here:</div><div><br></div><div>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.</div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div>Ok, I don’t see how splitting it out to a separate project helps that.</div></div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote"><div>Back to the proposal:</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>This help explain where I'm coming from here?</div></div></div></div></blockquote><br></div></div><div style="word-wrap:break-word"><div>No, this makes me even more concerned.</div></div></blockquote><div><br></div><div>Well, but it did explain ;)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>The entire original reason for the C API is to provide a stable interface for people who didn’t want to chase the C++ API (or didn’t want to chase *as much* of it).  In this sense, I consider the LLVM C API to be unlike the other “bindings” for generating IR: its purpose is to remain stable, not to be a language binding for people who prefer to write things in C.</div><div><br></div></div></blockquote><div><br></div><div>Which part of the C API is like bindings and which part is a stable API? There's no clear delineation right now.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div><div>If your claim is that the C API is too restrictive and prevents C++ evolution, then we just need to be careful about what we add to the C API.  Splitting it out to another project would not address this concern anyway, unless what you’re really saying is “we can break the C API even though it is trying to be stable, because its an external project”.</div></div></blockquote><div><br></div><div>What I'm saying is that we should leave the C API in as bindings support in and if someone actually designs an API worth considering stable then we can bring that into the project. I'm assuming an external iteration on this because I can't even imagine a) the amount of bikeshedding to an a priori proposal on the lists, and b) I imagine it would take some iteration to get it to something that works that isn't too tied to the IR format. The current set of C API (modulo the caveats I mentioned) are basically bindings. You have everything from location of calling convention to where in the IR the personality function is described as current C API - I don't think this is a good design for a stable API, it's too dependent upon the ordering of things in the IR in a way that is more strict than even what we can autoupgrade.</div><div><br></div><div>-eric </div></div></div>