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

James Knight wrote:
> It doesn't make sense to me to have the C API be less than a full
wrapping
> of the IR building functions. Having less than that, you almost might as
> well not have it at all. (Which would be sad.
As a data point, our approach in llvmlite (a lightweight LLVM binding
for Python -- http://llvmlite.pydata.org/) is to build the textual IR in
pure Python, to minimize the API contact surface with LLVM.  But even
with that approach, the LLVM C API is too limited for us - we have to
call the C++ API at times.
> I'd propose that the only 100% strict rule should be that if the
ABI/API
> changes, it is done in a way that *loudly* breaks old programs -- e.g. they
> fail to compile, link, or run (depending on how the other-lang wrappers are
> accessing the API functions) -- not that you get some random weird
> misbehavior because a function's argument types or return type has been
> changed.
I agree with this. Mandating that the C API is "100% stable" does not
seem to make a lot of sense when LLVM is changing so much otherwise, and
when you need to call C++ APIs anyway for non-toy applications...

Regards

Antoine.