[LLVMdev] LLVM as a shared library

[Filip Pizlo]

> On Aug 5, 2014, at 1:46 PM, Eric Christopher <echristo at gmail.com> wrote:
> 
>> (7) Make the C API truly great.
>> 
>> I think it’s harmful to LLVM in the long run if external embedders use the C++ API.  I think that one way of ensuring that they don’t have an excuse to do it is to flesh out some things:
>> 
>> - Add more tests of the C API to ensure that people don’t break it accidentally and to give more gravitas to the C API backwards compatibility claims.
>> - Increase C API coverage.
>>        - For example, WebKit currently sidesteps the C API to pass some commandline options to LLVM.  We don’t want that.
>>        - Add more support for reasoning about targets and triples.  WebKit still has to hardcode triples in some places even though it only ever does in-process JITing where host==target.  That’s weird.
>>        - Expose debugging and runtime stuff and make sure that there’s a coherent integration story with the MCJIT C API.
>>                - Currently it’s difficult to round-trip debug info: creating it in C is awkward and parsing DWARF sections that MCJIT generates involves lots of weirdness.  WebKit has its own DWARF parser for this, which shouldn’t be necessary.
>>                - WebKit is about to have its own copies of both a compactunwind and EH frame parser.  The contributor who “wrote” the EH frame parser actually just took it from LLVM.  The licenses are compatible, but nonetheless, copy-paste from LLVM into WebKit should be discouraged.
>> - Engage with non-WebKit embedders that currently use the C++ API to figure out what it would take to get them to switch to the C API.
>> 
>> I think that a lot of time when C API discussions arise, lots of embedders give excuses for using the C++ API.  WebKit used the C API for generating IR and even doing some IR manipulation, and for driving the MCJIT.  It’s been a positive experience and we enjoy the binary compatibility that it gives us.  I think it would be great to see if other embedders can do the same.
>> 
> 
> 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.

Can you come up with specific reasons why building a new API would be better for the community than maintaining the one we’ve got?

-Filip