<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 07/30/2015 03:46 PM, Eric
Christopher wrote:<br>
</div>
<blockquote
cite="mid:CALehDX4VDzD0aE4X29jt5Ycct-HU=f7TezPqvbRUn7H2=CUBGQ@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<br>
<div class="gmail_quote">
<div dir="ltr">On Thu, Jul 30, 2015 at 3:36 PM Philip Reames
<<a moz-do-not-send="true"
href="mailto:listmail@philipreames.com">listmail@philipreames.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div 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>
</div>
</blockquote>
<div><br>
</div>
<div>I'm fine with the stable API being in the main tree. I
proposed moving it out originally so that it could get some
work before moving it in. I'm reasonably confident that we
can get something working in tree for a stable API by the
next release though.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> 2) Everyone seemed
okay with the proposed deprecation policy for the stable
API.<br>
<br>
</div>
</blockquote>
<div><br>
</div>
<div>Yes.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Given this, I would
propose we designate the existing C API as the "hopefully
stable, but subject to future clean up per policy..."
Update </div>
</blockquote>
<div><br>
</div>
<div>This is where we disagree. I've tried to lay out a design
that I think would be good for a stable API and the current
one does not meet any guidelines there. It's too much a thin
wrapper on top of the existing C++ API. There's no clear
delineation for when/how/whether we extend it. It's already
easy to subtly break the existing one.</div>
<div><br>
</div>
<div>My proposal here is simply thus:</div>
<div><br>
</div>
<div>We deprecate the existing API as "moving to unstable".
For the next release cycle, as a new C API comes into
existence, we continue our best effort toward keeping the
existing API as stable as possible ("best effort") just like
we always have. At the next release we flip the switch that
says "this is now not stable, please use X". </div>
</div>
</div>
</blockquote>
I have no real objection to this, but I am also not a consumer of
the existing C API. I think this is a big enough change that we'd
need to make sure this got widely disseminated via a top-level RFC
email, LLVM Weekly, and the release notes. <br>
<blockquote
cite="mid:CALehDX4VDzD0aE4X29jt5Ycct-HU=f7TezPqvbRUn7H2=CUBGQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div>In the mean time we can either a) move a bindings level C
API into a separate directory starting with the existing
wrapped C++ API that we have as part of the C API, or b)
expand in the current directory and copy a set of APIs off
to another directory. How to do this with minimal churn in
external projects is important - this is why I'm inclined to
say that the bindings API reside in the current C API
directory, but others are more hesitant, I'm just not sure
in their mind how the final transition from "best effort
stable" to "stable".</div>
</div>
</div>
</blockquote>
I'm having a hard time parsing this paragraph. Specifically
"expand" what? and which API is transitioning? If I'm reading the
rest of your proposal right, we effectively won't have *any* stable
API in tree after the current one is downgraded to "unstable C
binding". What did I miss? <br>
<blockquote
cite="mid:CALehDX4VDzD0aE4X29jt5Ycct-HU=f7TezPqvbRUn7H2=CUBGQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote">
<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 bgcolor="#FFFFFF" text="#000000">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>
</div>
<div bgcolor="#FFFFFF" text="#000000"> <br>
Philip</div>
<div bgcolor="#FFFFFF" text="#000000"><br>
<br>
<div>On 07/30/2015 01:47 PM, Reid Kleckner wrote:<br>
</div>
</div>
<div bgcolor="#FFFFFF" text="#000000">
<blockquote 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></fieldset>
<br>
</blockquote>
</div>
<div bgcolor="#FFFFFF" text="#000000">
<blockquote type="cite">
<pre>_______________________________________________
LLVM Developers mailing list
<a moz-do-not-send="true" href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a moz-do-not-send="true" href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a>
<a moz-do-not-send="true" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
</pre>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
</body>
</html>