[LLVMdev] LLVM as a shared library

[Eric Christopher]

> (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.

-eric