<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sun, Aug 16, 2015 at 6:45 PM deadal nix via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><div><div>Chiming in with <a href="http://reviews.llvm.org/D10725" target="_blank">http://reviews.llvm.org/D10725</a><br><br></div>Being
 able to read and generate IR is at least some very basic thing we can 
agree on is needed. Can we get some testing for it ? Personally I don't 
really mind if this is going to be stable or not, but at least, having 
some test coverage would allow to take whatever path that is going to be
 taken willingly.<br><br></div></span></div></blockquote><div><br></div><div>Right, and that's the problem. Expanding the C API to cover reading and generating IR in a stable way will lock the C++ API down in a way that I'm not comfortable with - I think it has already gone too far.</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"><div dir="ltr"><span><div></div>I'd like also to remind all to not fall 
into the hypothetical nirvana fallacy, ie comparing proposed solution 
with an idealized and unrealized one. That's a good recipe for endless 
bikescheding when pretty much anythign would be better than the status 
quo.</span></div><div class="gmail_extra"><br><div class="gmail_quote">2015-07-17 12:36 GMT-07:00 Juergen Ributzka <span dir="ltr"><<a href="mailto:juergen@apple.com" target="_blank">juergen@apple.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi @ll,<br>
<br>
a few of us had recently a discussion about how to manage the C API and possible policies regarding addition, maintenance, deprecation, and removal of API.<br>
<br>
Even thought there is a strong agreement in the community that we shouldn't break released C API and should be backwards compatible, there doesn’t seem to be a developer policy that backs that up. This is something we should fix.<br>
<br>
I was wondering what the interested parties think of the current approach and what could/should we improve to make the use and maintenance of the C API easier for users and the developers alike.<br>
<br>
I was hoping we could also introduce a process that allows the removal of an API after it has been deprecated for a whole release and the release notes stated that it will be removed.<br>
<br>
Thoughts? Comments?<br>
<br>
Cheers,<br>
Juergen<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><br></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>         <a href="http://llvm.cs.uiuc.edu" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>