I think the idea of having a (hopefully not too) fluid C API that can encompass everything people want to be able to do in the language of their choice and calls into LLVM to do work sounds like a great idea. I think it would be useful to expand the number of people who are able to do research and development with LLVM without having to reinvent LLVM. That said, this is directly at odds with our desire to have a stable C API that can be supported long term (as you said at the end of the email). I.e. where do we draw the line on what can or should be added to the C API? What if the people that want the functionality are willing to deal with it being (occasionally) unstable? I don't agree with you that no one will take the time to design a well thought out C API. We've managed to get a lot of real world experience lately at both how these things will be used, and how we'll maintain such a thing. I think Juergen and others are a good group to come up with an answer to our engineering challenge. -eric On Thu, Jul 30, 2015 at 11:54 AM Reid Kleckner <rnk at google.com> wrote:> +1, I agree with keeping the existing C API stable, and requiring one > release of deprecation with an alternative in place to remove something > from it. > > Nobody is going to take the time to design a well-thought out C API that > is powerful enough for frontend IRGen and is forward compatible with future > versions of LLVM. That's an unsolved problem. We should stick with what we > have. > > The only thing we can do to keep LLVM flexible is to limit the set of new > things we expose over the C API boundary, which I'm totally in favor of. > > On Fri, Jul 17, 2015 at 12:36 PM, Juergen Ributzka <juergen at apple.com> > wrote: > >> Hi @ll, >> >> a few of us had recently a discussion about how to manage the C API and >> possible policies regarding addition, maintenance, deprecation, and removal >> of API. >> >> Even thought there is a strong agreement in the community that we >> shouldn't break released C API and should be backwards compatible, there >> doesn’t seem to be a developer policy that backs that up. This is something >> we should fix. >> >> I was wondering what the interested parties think of the current approach >> and what could/should we improve to make the use and maintenance of the C >> API easier for users and the developers alike. >> >> I was hoping we could also introduce a process that allows the removal of >> an API after it has been deprecated for a whole release and the release >> notes stated that it will be removed. >> >> Thoughts? Comments? >> >> Cheers, >> Juergen >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150730/8692fb81/attachment.html>
On Thu, Jul 30, 2015 at 1:04 PM, Eric Christopher <echristo at gmail.com> wrote:> I think the idea of having a (hopefully not too) fluid C API that can > encompass everything people want to be able to do in the language of their > choice and calls into LLVM to do work sounds like a great idea. I think it > would be useful to expand the number of people who are able to do research > and development with LLVM without having to reinvent LLVM. That said, this > is directly at odds with our desire to have a stable C API that can be > supported long term (as you said at the end of the email). I.e. where do we > draw the line on what can or should be added to the C API? What if the > people that want the functionality are willing to deal with it being > (occasionally) unstable? >Yeah, splitting the concerns of API completeness and API stability seems like a good idea. Right now we have clients like llgo that want to generate new debug info, and are perfectly happy to keep up to date with changes. They need a complete API, not a stable API, and our insistence on a stable C API has actually gotten in the way here.> I don't agree with you that no one will take the time to design a well > thought out C API. We've managed to get a lot of real world experience > lately at both how these things will be used, and how we'll maintain such a > thing. I think Juergen and others are a good group to come up with an > answer to our engineering challenge. >Sure, if people are planning to design a stable API that leave LLVM with more flexibility, then I'm all in favor of switching over to it. So far I haven't heard any new suggestions. I think any such design would probably be write-only, and revolve around sharing the bitcode auto-upgrade logic. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150730/95de5a69/attachment.html>
It's sounds like we've reached two rough conclusions: 1) We need both a stable and a non-stable fully featured C API. It's a somewhat open question whether both or either should be part of the main tree. 2) Everyone seemed okay with the proposed deprecation policy for the stable API. Given this, I would propose we designate the existing C API as the "hopefully stable, but subject to future clean up per policy..." Update the documentation to note that LLVM does not currently have a fully featured C API. Update the docs to reflect the deprecation policy for the existing C API. We can then start discussing how we should create the fully featured API. I'd lean towards a tool like Swig, but we could also do it purely on demand. For example, I could add some shims for the experimental GC support without committing to supporting the current APIs long term. Philip On 07/30/2015 01:47 PM, Reid Kleckner wrote:> On Thu, Jul 30, 2015 at 1:04 PM, Eric Christopher <echristo at gmail.com > <mailto:echristo at gmail.com>> wrote: > > I think the idea of having a (hopefully not too) fluid C API that > can encompass everything people want to be able to do in the > language of their choice and calls into LLVM to do work sounds > like a great idea. I think it would be useful to expand the number > of people who are able to do research and development with LLVM > without having to reinvent LLVM. That said, this is directly at > odds with our desire to have a stable C API that can be supported > long term (as you said at the end of the email). I.e. where do we > draw the line on what can or should be added to the C API? What if > the people that want the functionality are willing to deal with it > being (occasionally) unstable? > > > Yeah, splitting the concerns of API completeness and API stability > seems like a good idea. Right now we have clients like llgo that want > to generate new debug info, and are perfectly happy to keep up to date > with changes. They need a complete API, not a stable API, and our > insistence on a stable C API has actually gotten in the way here. > > I don't agree with you that no one will take the time to design a > well thought out C API. We've managed to get a lot of real world > experience lately at both how these things will be used, and how > we'll maintain such a thing. I think Juergen and others are a good > group to come up with an answer to our engineering challenge. > > > Sure, if people are planning to design a stable API that leave LLVM > with more flexibility, then I'm all in favor of switching over to it. > So far I haven't heard any new suggestions. I think any such design > would probably be write-only, and revolve around sharing the bitcode > auto-upgrade logic. > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150730/d7b08975/attachment.html>