[LLVMdev] LLVM as a shared library
Filip Pizlo
fpizlo at apple.com
Tue Aug 5 14:54:04 PDT 2014
> On Aug 5, 2014, at 2:13 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
>
>> Honestly I think if you want to make the C API great we should burn it
>> to the ground and come up with another one - and one that can be
>> versioned as well so we don't have the problems of being limited in
>> what we can do to llvm by needing compatibility with the C API.
>
> Or at least document what our backwards compatibility promises are and
> how we transition away from old APIs.
Right. I believe this is the right approach.
>
> Two examples where we do break C APIs:
>
> * An hypothetical off by one source range bug in clang. It will break
> a user of libclang that might have been compensating for the bug. In
> cases like this we seem to just assume there is a low risk and just
> fix the bug.
Yup.
Speaking for WebKit: we would be happy to get rid of workarounds even if it meant a brief period of breakage. We would handle that breakage on our end by ensuring that we don’t build the new (sans workaround) version of WebKit against the old (pre bugfix) version of LLVM or vice-versa. We’re OK with short-term pain for long-term gain.
>
> * Dropping features like the old JIT. It will break users of the C API
> that depend on the old JIT. In cases like this we provide an upgrade
> path (MCJIT) and a deprecation period.
Yup. I wonder how many people still use the old JIT via the C API. I know of old JIT users but I thought that many (most? all?) were using the C++ API.
-Filip
More information about the llvm-dev
mailing list