[llvm-dev] Improve JIT C API

[James Y Knight via llvm-dev]

On Sep 8, 2015, at 2:07 AM, Lang Hames <lhames at gmail.com> wrote:
> Hi James,
> 
> > And thus, if ORC is at that level (probably is?), I think it should just go in there with all the rest of them.
> 
> ORC is definitely not at that level yet - the attached patch was for a prototype of the APIs and lacks many features. If it goes in, I expect it to change reasonably quickly over the next few weeks/months as features are added and bugs uncovered and fixed. After that I would expect it to calm down a bit, but it'll be a while before it could approach the kind of stability described in the document you posted for review.

I had actually meant the underlying system, not the LLVM-C wrapper itself.

But, that's actually a good point which is not addressed by the draft policy: *when* do stability rules kick in? Instantaneously? A couple weeks of "oops" buffer time? The next release? Clearly, while a complex addition to the LLVM-C wrapper API is under development, its interface really cannot possibly be stable yet -- no matter what the underlying API's stability is, or what the intended stability is.

Saying that a stability policy doesn't apply until the next llvm release is attractive (and, is what the policy for IR changes says about IR compatibility). But my understanding is that a lot of people using llvm just work off of llvm trunk (and even make release branches from arbitrary points between releases), so that may not be the best policy?

Having the "unstable" directory be where under-active-development C API wrappers go while under development, and then graduating out when they're "done" makes some sense. That is: "unstable" should not be considered a final resting place for "unstable" APIs -- it's just for complex additions to the wrappers that are currently under development.

I'm a bit wary, because it seems like it could still end up a place where people will add stuff (better safe than sorry, so put it in unstable!), and then it will just get left there and never moved out, because that would take energy, and people are busy, and forget. So then you end up with a random subset of the API sitting in "unstable", despite being essentially unchanged for the last year or five. And of course other projects will have grown to depend on it by then, too.

Perhaps if the "install" build target excluded installing the headers from "unstable", too; that'd at least be a bit of incentive to move them out when they're ready, since it'll be annoying that they're not available in installed headers.