<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
+1<br>
<br>
Philip<br>
<br>
<div class="moz-cite-prefix">On 11/19/2015 01:56 PM, Eric
Christopher via llvm-dev wrote:<br>
</div>
<blockquote
cite="mid:CALehDX5r-46-qDWPO_j2p1g2EjDo-aXozctn07PdFvhbQckvXQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Hi All,</div>
<div><br>
</div>
<div>I wanted to send a follow-up mail to the C API
discussion/BoF that we had at the latest developer meeting and
nicely hosted by Justin and Juergen.</div>
<div><br>
</div>
<div>We were able to reach consensus on a number of
questions/concerns about the C API so I’m going to go ahead
and list them for posterity and for any further discussion
here:</div>
<div><br>
</div>
<div>Stability Guarantees:</div>
<div><br>
</div>
<div>The C API is, in general, a “best effort” for stability.
This means that we’ll make every attempt to keep the C API
stable, but that stability will be limited by the abstractness
of the interface and the stability of the C++ API that it
wraps. In practice, this means that things like “create debug
info” or “create this type of instruction” is likely to be
less stable than “take this IR file and JIT it for my current
machine”.</div>
<div>Release stability:</div>
<div>We won’t break the C API on the release branch with patches
that go on that branch - in general.</div>
<div>Exception: If we fix an unintentional C API break that will
keep us consistent with both the previous and next release.</div>
<div><br>
</div>
<div>Including new things into the API:</div>
<div><br>
</div>
<div>We’re going to adopt a policy of “if a particular LLVM
subcomponent has a C API already included, then expanding that
API is acceptable”, but we’re also going to institute a better
policy of “please test the API that you’ve just expanded”.
Hopefully this will get the C API better tested as time goes
on to remove accidental breakage so that any time we break the
C API we know about it.</div>
<div><br>
</div>
<div>Adding C API for subcomponents that don’t currently have
one is also fine, and the details of how best to do that
should be discussed on the mailing list as they come up.</div>
<div><br>
</div>
<div>Documentation:</div>
<div><br>
</div>
<div>We’re going to document this policy in the developer
documentation. In addition, any changes to the C API will
require documentation in the release notes so that it’s clear
to external users who do not follow the project how the C API
is changing and evolving.</div>
<div><br>
</div>
<div>What we expect this means in practice is that APIs like
libLTO and other APIs based on reading IR are going to remain
highly stable and that more wrapper like APIs (IR creation,
etc) are going to both be added and change as the underlying
IR changes.</div>
<div><br>
</div>
<div>Please feel free to follow up to this thread with any
concerns.</div>
<div><br>
</div>
<div>Thanks!</div>
<div><br>
</div>
<div>-eric (with Justin and Juergen)</div>
<span
id="docs-internal-guid-e8d98b73-21bc-774d-c46b-662eebb1cd3a">
<div><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">
</span></div>
</span></div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>