<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
It's sounds like we've reached two rough conclusions:<br>
1) We need both a stable and a non-stable fully featured C API.
It's a somewhat open question whether both or either should be part
of the main tree. <br>
2) Everyone seemed okay with the proposed deprecation policy for the
stable API.<br>
<br>
Given this, I would propose we designate the existing C API as the
"hopefully stable, but subject to future clean up per policy..."
Update the documentation to note that LLVM does not currently have a
fully featured C API. Update the docs to reflect the deprecation
policy for the existing C API. <br>
<br>
We can then start discussing how we should create the fully featured
API. I'd lean towards a tool like Swig, but we could also do it
purely on demand. For example, I could add some shims for the
experimental GC support without committing to supporting the current
APIs long term. <br>
<br>
Philip<br>
<br>
<div class="moz-cite-prefix">On 07/30/2015 01:47 PM, Reid Kleckner
wrote:<br>
</div>
<blockquote
cite="mid:CACs=ty+NJ9-pKCrU_K8cH4esiAKzz6e+8pno4YKm9q086Sp_DA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Thu, Jul 30, 2015 at 1:04 PM, Eric
Christopher <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>I think the idea of having a (hopefully not too)
fluid C API that can encompass everything people want
to be able to do in the language of their choice and
calls into LLVM to do work sounds like a great idea. I
think it would be useful to expand the number of
people who are able to do research and development
with LLVM without having to reinvent LLVM. That said,
this is directly at odds with our desire to have a
stable C API that can be supported long term (as you
said at the end of the email). I.e. where do we draw
the line on what can or should be added to the C API?
What if the people that want the functionality are
willing to deal with it being (occasionally) unstable?</div>
</div>
</blockquote>
<div><br>
</div>
<div>Yeah, splitting the concerns of API completeness and
API stability seems like a good idea. Right now we have
clients like llgo that want to generate new debug info,
and are perfectly happy to keep up to date with changes.
They need a complete API, not a stable API, and our
insistence on a stable C API has actually gotten in the
way here.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>I don't agree with you that no one will take the
time to design a well thought out C API. We've managed
to get a lot of real world experience lately at both
how these things will be used, and how we'll maintain
such a thing. I think Juergen and others are a good
group to come up with an answer to our engineering
challenge.</div>
</div>
</blockquote>
<div><br>
</div>
<div>Sure, if people are planning to design a stable API
that leave LLVM with more flexibility, then I'm all in
favor of switching over to it. So far I haven't heard any
new suggestions. I think any such design would probably be
write-only, and revolve around sharing the bitcode
auto-upgrade logic.</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a class="moz-txt-link-freetext" href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
</pre>
</blockquote>
<br>
</body>
</html>