<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 20, 2015, at 2:24 PM, Jim Grosbach <<a href="mailto:grosbach@apple.com" class="">grosbach@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 20, 2015, at 1:45 PM, Eric Christopher <<a href="mailto:echristo@gmail.com" class="">echristo@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Jul 20, 2015 at 1:37 PM Juergen Ributzka <<a href="mailto:juergen@apple.com" class="">juergen@apple.com</a>> wrote:<br class=""></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" class="">Wow, this went of topic very quickly ;-)<div class=""><br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">It did. I am sorry about that :)</div><div class=""> </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" class=""><div class=""></div><div class="">As you know I am very interested in an stable API (C and/or C++) for LLVM, but maybe we should discuss this in a separate thread. Designing a good stable API from scratch will take some time and until that point I want to document our current “tribal knowledge”. I will post a patch as you suggested.</div></div><div style="word-wrap:break-word" class=""><div class=""><br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">Thanks. Given the direction it's taken and the positive feedback I've gotten on the existing C API we might want to document it as "in flux" :)</div><div class=""><br class=""></div><div class="">That said, here's how I see this happening if we were to go the direction I'm proposing:</div><div class=""><br class=""></div><div class="">I think we should bite the bullet and say that the growth we've had in the C API is past what we were originally promising and just call the existing C API the "bindings" api. From there we can move the LTO headers to a new directory (insert bikeshed) and say that the existing code in llvm-c isn't stable. We can then migrate the things we want to be stable into a new directory with real stability guarantees. I'm seeing an API (possibly versioned) with a much lower surface area here similar, possibly, to the LTO stuff or libclang.<br class=""></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I’d prefer to do it the other way around. Make the new directory be for the bindings stuff. That way anything that works with what’s there as-is continues to do so. Any clients that need to move to the bindings API as we then work through deprecating things and otherwise cleaning up the stable API will be the ones that by definition want to opt-in to a less stable API and are thus more amenable to change. Changes for clients that are using the current API as a stable API will continue to work and will get the advance notice and transition planning from the deprecation process. If we make the stable API be in a new directory, that’s a build-time breaker right there for every client using the stable API. Let’s avoid that.</div></div></div></div></blockquote><div><br class=""></div><div>To clarify (I hope), what I care about here is that there is a clean migration path from the current structure to whatever new structure (and accordant API) we have. IMO, that’s easiest if we leave the current headers where they are and deprecate like crazy, but there are other ways (leaving behind copies w/ the entire file marked deprecated, e.g.). So long as there’s a migration path that doesn’t involve a hard break where clients are just screwed from one revision to the next, we should be fine.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""><br class=""></div><div class=""><div class="">I totally believe that existing clients could break through this and I want to minimize that as much as possible as it's our responsibility here. I think, in general, we've been stable enough in the existing C API to keep it going until we can define something that's actually stable that we can migrate clients to though.</div></div><div class=""><br class=""></div><div class="">Thoughts?</div><div class=""><br class=""></div><div class="">-eric</div><div class=""><br class=""></div><div class=""> </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" class=""><div class=""></div><div class="">—Juergen</div><div class=""><br class=""></div></div><div style="word-wrap:break-word" class=""><div class=""><div class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 20, 2015, at 1:08 PM, Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank" class="">echristo@gmail.com</a>> wrote:</div><br class=""></blockquote></div></div></div></div></div></div><div style="word-wrap:break-word" class=""><div class=""><div class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">Part (most?) of the point of having a stable API is as a way of decoupling the development processes of two separate projects (modulo well-documented release-to-release updating). Requiring our users to add tests in our tree doesn't really achieve much decoupling. </div></div></div></div></div></blockquote><div class=""><br class=""></div></div></div><div style="word-wrap:break-word" class=""><div class=""><div class="">I’m not sure there is much “coupling” here. The point is that we expose a C API that is supposed to be stable but is not well tested. And some part of the C API is just a wrapper around the C++ and hasn’t really been designed to be “stable” in time.</div><div class="">It seems also that we don’t really know what part of the C API really needs to be stable and is important for the users, so I read Pete’s proposal as “let’s collect the current use-cases and make them tests in LLVM, so that we define what is part of the stable C API and so that we won’t (inadvertently) break valid use cases".</div><div class=""><br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">Yeah, this is just terrible though for all of the reasons I raised in my email and as you even say here "And some part of the C API is just a wrapper around the C++ and hasn’t really been designed to be “stable” in time."</div><div class=""> </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" class=""><div class=""><div class=""><br class=""></div><div class="">As of having this in-tree or out-of-tree, I’m not sure about that and there is a trade-off.</div><div class=""><br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">I'm regretting ever saying "out of tree" here as I don't think it's the main issue, rather the splitting of the "bindings" style of api that we see a lot of in the C API directory and the more solid ones that we see from libclang and liblto.</div><div class=""><br class=""></div><div class="">-eric </div></div></div></div></blockquote></div></div></div></div></div></div><div style="word-wrap:break-word" class=""><div class=""><div class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class="">
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank" class="">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu/" target="_blank" class="">http://llvm.cs.uiuc.edu</a><br class=""><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br class=""></div></blockquote></div></div></div></div></div></div></blockquote></div></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:LLVMdev@cs.uiuc.edu" class="">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu/" class="">http://llvm.cs.uiuc.edu</a><br class=""><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></body></html>