Lang, aren't you going to be the major (only?) player when it comes to Orc APIs, if you're not opposed to it having them in the C bindings proper will certainly help. That's my vote, I understand it is different from the previous cases but the API surface area here is relatively small. On Mon, Sep 7, 2015 at 5:37 PM, Lang Hames <lhames at gmail.com> wrote:> Hi Jauhien, > > A few people have requested a C API for ORC. I don't think ORC's ready for a > stable C API, but I'm not opposed to providing C bindings that will probably > be reasonably stable in practice (though with no guarantees). I've actually > already knocked up some trivial prototype bindings for Hayden Livingston > that could serve as a base (see attached). > > The next question is where unstable bindings should live. Juergen, Eric, > anyone else who wants to weigh in: I looked back over the C API thread, but > I don't think we settled on a home for this kind of thing. Any thoughts? I > could see either introducing a new include directory (something along the > lines of include/llvm/llvm-c-bindings) or a new c-bindings project on > llvm.org. The former would put all LLVM developers on the hook for > maintaining the bindings, the latter would leave maintenance to users of the > bindings project, and any volunteers. I prefer the second option: I don't > think core developers should be on the hook for maintaining unstable > bindings - that kind of special treatment should be reserved for the stable > API. > > Cheers, > Lang. > > > On Sun, Sep 6, 2015 at 1:52 PM, Jauhien Piatlicki via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> Hi all, >> >> I would like to have better C API for LLVM JIT, as I have plans to use >> it from Rust. I've sent already a patch [1] that adds possibility to >> create custom memory managers based on SectionMemoryManager using C API. >> >> What I would like to have now is a possibility to access ORC through C >> API somehow. The problem here is that ORC uses templates heavily. So I'm >> looking for any suggestions on how to better wrap its functionality for C. >> >> Also I would thank everybody who'll review my already sent patch. >> >> [1] http://reviews.llvm.org/D12607 >> >> -- >> Jauhien >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >
Hi Hayden, Eric, I'm not sure what you mean by "C bindings proper"? Historically the C API has set a high bar on stability, and I'm not willing/able to guarantee that level of stability yet. So it's a matter of determining where we should put C bindings that don't meet the bar for inclusion in "stable". Eric - Assuming that people want these in the llvm tree rather than in a separate project, I think 'include/llvm-c/unstable' seems like a good starting point. We can move it later if/when we come up with something better. Cheers, Lang. On Mon, Sep 7, 2015 at 9:50 PM, Hayden Livingston <halivingston at gmail.com> wrote:> Lang, aren't you going to be the major (only?) player when it comes to > Orc APIs, if you're not opposed to it having them in the C bindings > proper will certainly help. That's my vote, I understand it is > different from the previous cases but the API surface area here is > relatively small. > > On Mon, Sep 7, 2015 at 5:37 PM, Lang Hames <lhames at gmail.com> wrote: > > Hi Jauhien, > > > > A few people have requested a C API for ORC. I don't think ORC's ready > for a > > stable C API, but I'm not opposed to providing C bindings that will > probably > > be reasonably stable in practice (though with no guarantees). I've > actually > > already knocked up some trivial prototype bindings for Hayden Livingston > > that could serve as a base (see attached). > > > > The next question is where unstable bindings should live. Juergen, Eric, > > anyone else who wants to weigh in: I looked back over the C API thread, > but > > I don't think we settled on a home for this kind of thing. Any thoughts? > I > > could see either introducing a new include directory (something along the > > lines of include/llvm/llvm-c-bindings) or a new c-bindings project on > > llvm.org. The former would put all LLVM developers on the hook for > > maintaining the bindings, the latter would leave maintenance to users of > the > > bindings project, and any volunteers. I prefer the second option: I don't > > think core developers should be on the hook for maintaining unstable > > bindings - that kind of special treatment should be reserved for the > stable > > API. > > > > Cheers, > > Lang. > > > > > > On Sun, Sep 6, 2015 at 1:52 PM, Jauhien Piatlicki via llvm-dev > > <llvm-dev at lists.llvm.org> wrote: > >> > >> Hi all, > >> > >> I would like to have better C API for LLVM JIT, as I have plans to use > >> it from Rust. I've sent already a patch [1] that adds possibility to > >> create custom memory managers based on SectionMemoryManager using C API. > >> > >> What I would like to have now is a possibility to access ORC through C > >> API somehow. The problem here is that ORC uses templates heavily. So I'm > >> looking for any suggestions on how to better wrap its functionality for > C. > >> > >> Also I would thank everybody who'll review my already sent patch. > >> > >> [1] http://reviews.llvm.org/D12607 > >> > >> -- > >> Jauhien > >> > >> > >> _______________________________________________ > >> LLVM Developers mailing list > >> llvm-dev at lists.llvm.org > >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >> > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150907/7e2098e3/attachment.html>
On Mon, Sep 7, 2015 at 10:17 PM Lang Hames <lhames at gmail.com> wrote:> Hi Hayden, Eric, > > I'm not sure what you mean by "C bindings proper"? Historically the C API > has set a high bar on stability, and I'm not willing/able to guarantee that > level of stability yet. So it's a matter of determining where we should put > C bindings that don't meet the bar for inclusion in "stable". > > Eric - Assuming that people want these in the llvm tree rather than in a > separate project, I think 'include/llvm-c/unstable' seems like a good > starting point. We can move it later if/when we come up with something > better. > >Up to you. -eric> Cheers, > Lang. > > > > On Mon, Sep 7, 2015 at 9:50 PM, Hayden Livingston <halivingston at gmail.com> > wrote: > >> Lang, aren't you going to be the major (only?) player when it comes to >> Orc APIs, if you're not opposed to it having them in the C bindings >> proper will certainly help. That's my vote, I understand it is >> different from the previous cases but the API surface area here is >> relatively small. >> >> On Mon, Sep 7, 2015 at 5:37 PM, Lang Hames <lhames at gmail.com> wrote: >> > Hi Jauhien, >> > >> > A few people have requested a C API for ORC. I don't think ORC's ready >> for a >> > stable C API, but I'm not opposed to providing C bindings that will >> probably >> > be reasonably stable in practice (though with no guarantees). I've >> actually >> > already knocked up some trivial prototype bindings for Hayden Livingston >> > that could serve as a base (see attached). >> > >> > The next question is where unstable bindings should live. Juergen, Eric, >> > anyone else who wants to weigh in: I looked back over the C API thread, >> but >> > I don't think we settled on a home for this kind of thing. Any >> thoughts? I >> > could see either introducing a new include directory (something along >> the >> > lines of include/llvm/llvm-c-bindings) or a new c-bindings project on >> > llvm.org. The former would put all LLVM developers on the hook for >> > maintaining the bindings, the latter would leave maintenance to users >> of the >> > bindings project, and any volunteers. I prefer the second option: I >> don't >> > think core developers should be on the hook for maintaining unstable >> > bindings - that kind of special treatment should be reserved for the >> stable >> > API. >> > >> > Cheers, >> > Lang. >> > >> > >> > On Sun, Sep 6, 2015 at 1:52 PM, Jauhien Piatlicki via llvm-dev >> > <llvm-dev at lists.llvm.org> wrote: >> >> >> >> Hi all, >> >> >> >> I would like to have better C API for LLVM JIT, as I have plans to use >> >> it from Rust. I've sent already a patch [1] that adds possibility to >> >> create custom memory managers based on SectionMemoryManager using C >> API. >> >> >> >> What I would like to have now is a possibility to access ORC through C >> >> API somehow. The problem here is that ORC uses templates heavily. So >> I'm >> >> looking for any suggestions on how to better wrap its functionality >> for C. >> >> >> >> Also I would thank everybody who'll review my already sent patch. >> >> >> >> [1] http://reviews.llvm.org/D12607 >> >> >> >> -- >> >> Jauhien >> >> >> >> >> >> _______________________________________________ >> >> LLVM Developers mailing list >> >> llvm-dev at lists.llvm.org >> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >> > >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150908/fcbc6425/attachment.html>
Hi Lang, Hayden, On 09/08/2015 07:17 AM, Lang Hames wrote:> Hi Hayden, Eric, > > I'm not sure what you mean by "C bindings proper"? Historically the C > API has set a high bar on stability, and I'm not willing/able to > guarantee that level of stability yet. So it's a matter of determining > where we should put C bindings that don't meet the bar for inclusion in > "stable". > > Eric - Assuming that people want these in the llvm tree rather than in a > separate project, I think 'include/llvm-c/unstable' seems like a good > starting point. We can move it later if/when we come up with something > better.+ 1 from me for 'include/llvm-c/unstable'. This kind of staging area for unstable API looks reasonable. -- Jauhien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150908/74ba3e43/attachment.sig>