llvm dev - Jul 2015 - [LLVMdev] [RFC] Developer Policy for LLVM C API

On 07/17/2015 02:05 PM, Rafael Espíndola wrote:
>> c) One of the big things appears to be the push and pull for "A C
API for
>> all C++ entry points" along with "We don't want to get
locked into
>> immobility because we have a C API for all C++ entry points".
Perhaps part
>> of this might be defining an actual stable set of things along with an
>> unstable set of things?
> This is a good idea. We should clearly document a subset that is stable.
>
> Being stable should also have a very high bar. Things like "we have a
> shipping product that has to work with two versions of llvm and has to
> dynamic link with it".
+1 to the general notion of stable vs unstable
>
> So something that the webkit jit needs is in. Some API that is in C
> just so someone can statically link a C/Go/Ocaml program with llvm is
> not.
-1 to this particular definition thereof
>
> Cheers,
> Rafael
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

>> So something that the webkit jit needs is in. Some API that is in C
>> just so someone can statically link a C/Go/Ocaml program with llvm is
>> not.
>
> -1 to this particular definition thereof
Not a definition, just an example of something that has a reason to
use dynamic linking and work with multiple versions of llvm.

Cheers,
Rafael

Can we also codify when something should be added to the C API? For a
lot of folks the C API is the only usable interface. I am one of them.

We are not as vocally represented because don't generally give back to
the community, usually because we are just consumers of this library.
(Or maybe I'm totally wrong and lots of us give back).

For example, ORC APIs in C the bindings.

On Fri, Jul 17, 2015 at 2:42 PM, Rafael Espíndola
<rafael.espindola at gmail.com> wrote:
>>> So something that the webkit jit needs is in. Some API that is in C
>>> just so someone can statically link a C/Go/Ocaml program with llvm
is
>>> not.
>>
>> -1 to this particular definition thereof
>
> Not a definition, just an example of something that has a reason to
> use dynamic linking and work with multiple versions of llvm.
>
> Cheers,
> Rafael
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev