While I understand the people committing to the primarily C++ codebase of LLVM find it as additional burden, far more number of people enjoy the benefits of an official LLVM C API support than are vocal here. While Clang maybe the first-class LLVM citizen for the foreseeable future, I can tell you LLVM is used in many more situations (I'm talking about Rust, Go, Julia, DLang, etc.) than this alias realized. I alone am using it interesting projects I hope to release sometime this year and all of these projects rely on the comfort of the "official" C API. I sympathize with the community that is not using them but having to still maintain and fix bugs. To those of you (on this thread and others) who are wanting to remove the C API from the project, please tell the community what can be done to improve the situation. Do we need bots? People writing tests? I would like to put my support behind discouraging the idea of pushing the bindings to a side project. On Sun, Jul 19, 2015 at 7:24 PM, Eric Christopher <echristo at gmail.com> wrote:> Hi Chris, > > On Sun, Jul 19, 2015 at 9:16 AM Chris Lattner <clattner at apple.com> wrote: >> >> On Jul 18, 2015, at 11:27 AM, Hal Finkel <hfinkel at anl.gov> wrote: >> >> I am strongly in favor of moving the bindings, C or otherwise, to >> >> another project. >> > >> > I agree. From my viewpoint we have two primary problems with the C API: >> > >> > 1. Many of the LLVM contributors don't use it, and thus, don't have a >> > great understanding of how it can be most-usefully updated/improved, and >> > what functionality needs to be exposed. We have most, but not all, >> > transformations; many, but not all, IR features, etc. >> > >> > 2. We don't have a good set of tests for it, nor do we have a good set >> > of tutorials/documentation for it. Our tutorials, specifically, are in C++, >> > not in C. We could break the C API and we'd likely remain unaware for quite >> > awhile. >> > >> > Putting it in a separate project will force those who have a stake in >> > its existence to take the responsibility of moving it forward. Separate >> > project, or not, however, we should have a better developer policy regarding >> > the C API (and the other bindings) that fall under the LLVM umbrella. >> > Specifically, we should outline what features need to be exposed, and we >> > should actively maintain (and test for) full coverage of those features. >> >> I don’t understand the motivation for this. Is there tension between >> clients of the C API that would warrant having different >> approaches/implementations? Moving it out to a subproject to get better >> testing seems a bit silly. >> >> Personally, unless there is a strong and compelling reason to do so, I’d >> prefer to keep a single set of C bindings to encourage standardization and >> avoid fragmenting the community. >> > > So, I made this proposal for what I think is a pretty good reason. There's > an "unofficial" as Juergen said, policy that the C API is the stable API. > There's nothing wrong with a stable C API, but that's what I'm proposing > should move out of tree to where those that are most concerned with it can > develop it and ensure that it remains stable for whatever guarantees they > want. > > Some background here: > > Right now we definitely have this dichotomy between a "bindings" C API and a > "stable" C API. The unofficial policy as I mentioned above is that there's > one C API and that's the stable API. Over the last 3-5 years or so the > "stable" C API has started growing in ways that encompass just about every > class and API in llvm. We've occasionally denied bindings level API support > because we knew the code in that area was going to change - but just imagine > we'd let a few of them in, we wouldn't have been able to do the IR/Metadata > split at all. As it is we technically broke the C API, just not in a way > that any external user cared about. > > Back to the proposal: > > What I'm proposing is that we make the C API that exists in tree a bindings > API that has the same stability guarantees as the C++ API. Honestly it'll > probably much more stable, but at least then we won't have to worry or > revert work because the C API was "too close to the machine" or rather the > C++ code. This means that someone that wants a stable C API can go off and > develop one (tests and all) and we can possibly look at bringing it back > into tree at some point in the future. For example, if someone comes up with > a good "libjit" api then we can look at how the API design works and make > sure it's general enough that it's not going to cause undue solidification > of the existing APIs. > > Caveat: I'm not talking about the existing libclang or liblto libraries. > Those seem to work and have a small enough API surface that they seem > reasonable to support and we can move to a new API if they seem to be > hindering development in the future. > > This help explain where I'm coming from here? > > Thanks! > > -eric > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
On Sun, Jul 19, 2015 at 8:37 PM Hayden Livingston <halivingston at gmail.com> wrote:> While I understand the people committing to the primarily C++ codebase > of LLVM find it as additional burden, far more number of people enjoy > the benefits of an official LLVM C API support than are vocal here. > > While Clang maybe the first-class LLVM citizen for the foreseeable > future, I can tell you LLVM is used in many more situations (I'm > talking about Rust, Go, Julia, DLang, etc.) than this alias realized. > I alone am using it interesting projects I hope to release sometime > this year and all of these projects rely on the comfort of the > "official" C API. > >I can assure you I'm more than well aware of all of these projects and more.> I sympathize with the community that is not using them but having to > still maintain and fix bugs. To those of you (on this thread and > others) who are wanting to remove the C API from the project, please > tell the community what can be done to improve the situation. Do we > need bots? People writing tests? > >I want to not have to hamstring the progress of the project in order to maintain a stable API across the entire project that I don't have to do with the C++ API.> I would like to put my support behind discouraging the idea of pushing > the bindings to a side project. > >I don't think you understood my email very well. "bindings" I'm fine with keeping as part of project, just with the same stability guarantees as any other part of the code base. A "stable" C API that "must not break", not so much. -eric> On Sun, Jul 19, 2015 at 7:24 PM, Eric Christopher <echristo at gmail.com> > wrote: > > Hi Chris, > > > > On Sun, Jul 19, 2015 at 9:16 AM Chris Lattner <clattner at apple.com> > wrote: > >> > >> On Jul 18, 2015, at 11:27 AM, Hal Finkel <hfinkel at anl.gov> wrote: > >> >> I am strongly in favor of moving the bindings, C or otherwise, to > >> >> another project. > >> > > >> > I agree. From my viewpoint we have two primary problems with the C > API: > >> > > >> > 1. Many of the LLVM contributors don't use it, and thus, don't have a > >> > great understanding of how it can be most-usefully updated/improved, > and > >> > what functionality needs to be exposed. We have most, but not all, > >> > transformations; many, but not all, IR features, etc. > >> > > >> > 2. We don't have a good set of tests for it, nor do we have a good set > >> > of tutorials/documentation for it. Our tutorials, specifically, are > in C++, > >> > not in C. We could break the C API and we'd likely remain unaware for > quite > >> > awhile. > >> > > >> > Putting it in a separate project will force those who have a stake in > >> > its existence to take the responsibility of moving it forward. > Separate > >> > project, or not, however, we should have a better developer policy > regarding > >> > the C API (and the other bindings) that fall under the LLVM umbrella. > >> > Specifically, we should outline what features need to be exposed, and > we > >> > should actively maintain (and test for) full coverage of those > features. > >> > >> I don’t understand the motivation for this. Is there tension between > >> clients of the C API that would warrant having different > >> approaches/implementations? Moving it out to a subproject to get better > >> testing seems a bit silly. > >> > >> Personally, unless there is a strong and compelling reason to do so, I’d > >> prefer to keep a single set of C bindings to encourage standardization > and > >> avoid fragmenting the community. > >> > > > > So, I made this proposal for what I think is a pretty good reason. > There's > > an "unofficial" as Juergen said, policy that the C API is the stable API. > > There's nothing wrong with a stable C API, but that's what I'm proposing > > should move out of tree to where those that are most concerned with it > can > > develop it and ensure that it remains stable for whatever guarantees they > > want. > > > > Some background here: > > > > Right now we definitely have this dichotomy between a "bindings" C API > and a > > "stable" C API. The unofficial policy as I mentioned above is that > there's > > one C API and that's the stable API. Over the last 3-5 years or so the > > "stable" C API has started growing in ways that encompass just about > every > > class and API in llvm. We've occasionally denied bindings level API > support > > because we knew the code in that area was going to change - but just > imagine > > we'd let a few of them in, we wouldn't have been able to do the > IR/Metadata > > split at all. As it is we technically broke the C API, just not in a way > > that any external user cared about. > > > > Back to the proposal: > > > > What I'm proposing is that we make the C API that exists in tree a > bindings > > API that has the same stability guarantees as the C++ API. Honestly it'll > > probably much more stable, but at least then we won't have to worry or > > revert work because the C API was "too close to the machine" or rather > the > > C++ code. This means that someone that wants a stable C API can go off > and > > develop one (tests and all) and we can possibly look at bringing it back > > into tree at some point in the future. For example, if someone comes up > with > > a good "libjit" api then we can look at how the API design works and make > > sure it's general enough that it's not going to cause undue > solidification > > of the existing APIs. > > > > Caveat: I'm not talking about the existing libclang or liblto libraries. > > Those seem to work and have a small enough API surface that they seem > > reasonable to support and we can move to a new API if they seem to be > > hindering development in the future. > > > > This help explain where I'm coming from here? > > > > Thanks! > > > > -eric > > > > _______________________________________________ > > 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/20150720/b7842ebf/attachment.html>
----- Original Message -----> From: "Hayden Livingston" <halivingston at gmail.com> > To: "Eric Christopher" <echristo at gmail.com> > Cc: "Chris Lattner" <clattner at apple.com>, "Hal Finkel" <hfinkel at anl.gov>, "LLVM Dev" <llvmdev at cs.uiuc.edu>, "Lang > Hames" <lhames at apple.com> > Sent: Sunday, July 19, 2015 10:37:11 PM > Subject: Re: [LLVMdev] [RFC] Developer Policy for LLVM C API > > While I understand the people committing to the primarily C++ > codebase > of LLVM find it as additional burden, far more number of people enjoy > the benefits of an official LLVM C API support than are vocal here. > > While Clang maybe the first-class LLVM citizen for the foreseeable > future, I can tell you LLVM is used in many more situations (I'm > talking about Rust, Go, Julia, DLang, etc.) than this alias realized. > I alone am using it interesting projects I hope to release sometime > this year and all of these projects rely on the comfort of the > "official" C API.Do you require long-term cross-release ABI and/or API stability from the C API that you're using? Do these other projects? FWIW, many of us (most I'd guess) are well aware of Rust, Go, Julia, etc. and are excited to see them.> > I sympathize with the community that is not using them but having to > still maintain and fix bugs. To those of you (on this thread and > others) who are wanting to remove the C API from the project, please > tell the community what can be done to improve the situation. Do we > need bots? People writing tests?Regardless, we certainly need tests.> > I would like to put my support behind discouraging the idea of > pushing > the bindings to a side project.Clang is a side project ;) -Hal> > On Sun, Jul 19, 2015 at 7:24 PM, Eric Christopher > <echristo at gmail.com> wrote: > > Hi Chris, > > > > On Sun, Jul 19, 2015 at 9:16 AM Chris Lattner <clattner at apple.com> > > wrote: > >> > >> On Jul 18, 2015, at 11:27 AM, Hal Finkel <hfinkel at anl.gov> wrote: > >> >> I am strongly in favor of moving the bindings, C or otherwise, > >> >> to > >> >> another project. > >> > > >> > I agree. From my viewpoint we have two primary problems with the > >> > C API: > >> > > >> > 1. Many of the LLVM contributors don't use it, and thus, don't > >> > have a > >> > great understanding of how it can be most-usefully > >> > updated/improved, and > >> > what functionality needs to be exposed. We have most, but not > >> > all, > >> > transformations; many, but not all, IR features, etc. > >> > > >> > 2. We don't have a good set of tests for it, nor do we have a > >> > good set > >> > of tutorials/documentation for it. Our tutorials, specifically, > >> > are in C++, > >> > not in C. We could break the C API and we'd likely remain > >> > unaware for quite > >> > awhile. > >> > > >> > Putting it in a separate project will force those who have a > >> > stake in > >> > its existence to take the responsibility of moving it forward. > >> > Separate > >> > project, or not, however, we should have a better developer > >> > policy regarding > >> > the C API (and the other bindings) that fall under the LLVM > >> > umbrella. > >> > Specifically, we should outline what features need to be > >> > exposed, and we > >> > should actively maintain (and test for) full coverage of those > >> > features. > >> > >> I don’t understand the motivation for this. Is there tension > >> between > >> clients of the C API that would warrant having different > >> approaches/implementations? Moving it out to a subproject to get > >> better > >> testing seems a bit silly. > >> > >> Personally, unless there is a strong and compelling reason to do > >> so, I’d > >> prefer to keep a single set of C bindings to encourage > >> standardization and > >> avoid fragmenting the community. > >> > > > > So, I made this proposal for what I think is a pretty good reason. > > There's > > an "unofficial" as Juergen said, policy that the C API is the > > stable API. > > There's nothing wrong with a stable C API, but that's what I'm > > proposing > > should move out of tree to where those that are most concerned with > > it can > > develop it and ensure that it remains stable for whatever > > guarantees they > > want. > > > > Some background here: > > > > Right now we definitely have this dichotomy between a "bindings" C > > API and a > > "stable" C API. The unofficial policy as I mentioned above is that > > there's > > one C API and that's the stable API. Over the last 3-5 years or so > > the > > "stable" C API has started growing in ways that encompass just > > about every > > class and API in llvm. We've occasionally denied bindings level API > > support > > because we knew the code in that area was going to change - but > > just imagine > > we'd let a few of them in, we wouldn't have been able to do the > > IR/Metadata > > split at all. As it is we technically broke the C API, just not in > > a way > > that any external user cared about. > > > > Back to the proposal: > > > > What I'm proposing is that we make the C API that exists in tree a > > bindings > > API that has the same stability guarantees as the C++ API. Honestly > > it'll > > probably much more stable, but at least then we won't have to worry > > or > > revert work because the C API was "too close to the machine" or > > rather the > > C++ code. This means that someone that wants a stable C API can go > > off and > > develop one (tests and all) and we can possibly look at bringing it > > back > > into tree at some point in the future. For example, if someone > > comes up with > > a good "libjit" api then we can look at how the API design works > > and make > > sure it's general enough that it's not going to cause undue > > solidification > > of the existing APIs. > > > > Caveat: I'm not talking about the existing libclang or liblto > > libraries. > > Those seem to work and have a small enough API surface that they > > seem > > reasonable to support and we can move to a new API if they seem to > > be > > hindering development in the future. > > > > This help explain where I'm coming from here? > > > > Thanks! > > > > -eric > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
On Mon, 20 Jul 2015 at 12:49 Hal Finkel <hfinkel at anl.gov> wrote:> ----- Original Message ----- > > From: "Hayden Livingston" <halivingston at gmail.com> > > To: "Eric Christopher" <echristo at gmail.com> > > Cc: "Chris Lattner" <clattner at apple.com>, "Hal Finkel" <hfinkel at anl.gov>, > "LLVM Dev" <llvmdev at cs.uiuc.edu>, "Lang > > Hames" <lhames at apple.com> > > Sent: Sunday, July 19, 2015 10:37:11 PM > > Subject: Re: [LLVMdev] [RFC] Developer Policy for LLVM C API > > > > While I understand the people committing to the primarily C++ > > codebase > > of LLVM find it as additional burden, far more number of people enjoy > > the benefits of an official LLVM C API support than are vocal here. > > > > While Clang maybe the first-class LLVM citizen for the foreseeable > > future, I can tell you LLVM is used in many more situations (I'm > > talking about Rust, Go, Julia, DLang, etc.) than this alias realized. > > I alone am using it interesting projects I hope to release sometime > > this year and all of these projects rely on the comfort of the > > "official" C API. > > Do you require long-term cross-release ABI and/or API stability from the C > API that you're using? Do these other projects? FWIW, many of us (most I'd > guess) are well aware of Rust, Go, Julia, etc. and are excited to see them. >FWIW, neither the Go bindings nor llgo require that. The Go bindings API itself is not stable; there's not a lot of change, but it does happen. Also, the Go bindings exposes bits of the C++ API (DIBuilder) that are not available through the C API. Cheers, Andrew> > > I sympathize with the community that is not using them but having to > > still maintain and fix bugs. To those of you (on this thread and > > others) who are wanting to remove the C API from the project, please > > tell the community what can be done to improve the situation. Do we > > need bots? People writing tests? > > Regardless, we certainly need tests. > > > > > I would like to put my support behind discouraging the idea of > > pushing > > the bindings to a side project. > > Clang is a side project ;) > > -Hal > > > > > On Sun, Jul 19, 2015 at 7:24 PM, Eric Christopher > > <echristo at gmail.com> wrote: > > > Hi Chris, > > > > > > On Sun, Jul 19, 2015 at 9:16 AM Chris Lattner <clattner at apple.com> > > > wrote: > > >> > > >> On Jul 18, 2015, at 11:27 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > >> >> I am strongly in favor of moving the bindings, C or otherwise, > > >> >> to > > >> >> another project. > > >> > > > >> > I agree. From my viewpoint we have two primary problems with the > > >> > C API: > > >> > > > >> > 1. Many of the LLVM contributors don't use it, and thus, don't > > >> > have a > > >> > great understanding of how it can be most-usefully > > >> > updated/improved, and > > >> > what functionality needs to be exposed. We have most, but not > > >> > all, > > >> > transformations; many, but not all, IR features, etc. > > >> > > > >> > 2. We don't have a good set of tests for it, nor do we have a > > >> > good set > > >> > of tutorials/documentation for it. Our tutorials, specifically, > > >> > are in C++, > > >> > not in C. We could break the C API and we'd likely remain > > >> > unaware for quite > > >> > awhile. > > >> > > > >> > Putting it in a separate project will force those who have a > > >> > stake in > > >> > its existence to take the responsibility of moving it forward. > > >> > Separate > > >> > project, or not, however, we should have a better developer > > >> > policy regarding > > >> > the C API (and the other bindings) that fall under the LLVM > > >> > umbrella. > > >> > Specifically, we should outline what features need to be > > >> > exposed, and we > > >> > should actively maintain (and test for) full coverage of those > > >> > features. > > >> > > >> I don’t understand the motivation for this. Is there tension > > >> between > > >> clients of the C API that would warrant having different > > >> approaches/implementations? Moving it out to a subproject to get > > >> better > > >> testing seems a bit silly. > > >> > > >> Personally, unless there is a strong and compelling reason to do > > >> so, I’d > > >> prefer to keep a single set of C bindings to encourage > > >> standardization and > > >> avoid fragmenting the community. > > >> > > > > > > So, I made this proposal for what I think is a pretty good reason. > > > There's > > > an "unofficial" as Juergen said, policy that the C API is the > > > stable API. > > > There's nothing wrong with a stable C API, but that's what I'm > > > proposing > > > should move out of tree to where those that are most concerned with > > > it can > > > develop it and ensure that it remains stable for whatever > > > guarantees they > > > want. > > > > > > Some background here: > > > > > > Right now we definitely have this dichotomy between a "bindings" C > > > API and a > > > "stable" C API. The unofficial policy as I mentioned above is that > > > there's > > > one C API and that's the stable API. Over the last 3-5 years or so > > > the > > > "stable" C API has started growing in ways that encompass just > > > about every > > > class and API in llvm. We've occasionally denied bindings level API > > > support > > > because we knew the code in that area was going to change - but > > > just imagine > > > we'd let a few of them in, we wouldn't have been able to do the > > > IR/Metadata > > > split at all. As it is we technically broke the C API, just not in > > > a way > > > that any external user cared about. > > > > > > Back to the proposal: > > > > > > What I'm proposing is that we make the C API that exists in tree a > > > bindings > > > API that has the same stability guarantees as the C++ API. Honestly > > > it'll > > > probably much more stable, but at least then we won't have to worry > > > or > > > revert work because the C API was "too close to the machine" or > > > rather the > > > C++ code. This means that someone that wants a stable C API can go > > > off and > > > develop one (tests and all) and we can possibly look at bringing it > > > back > > > into tree at some point in the future. For example, if someone > > > comes up with > > > a good "libjit" api then we can look at how the API design works > > > and make > > > sure it's general enough that it's not going to cause undue > > > solidification > > > of the existing APIs. > > > > > > Caveat: I'm not talking about the existing libclang or liblto > > > libraries. > > > Those seem to work and have a small enough API surface that they > > > seem > > > reasonable to support and we can move to a new API if they seem to > > > be > > > hindering development in the future. > > > > > > This help explain where I'm coming from here? > > > > > > Thanks! > > > > > > -eric > > > > > > _______________________________________________ > > > LLVM Developers mailing list > > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > > -- > Hal Finkel > Assistant Computational Scientist > Leadership Computing Facility > Argonne National Laboratory > > _______________________________________________ > 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/20150720/0154a234/attachment.html>
Hal Finkel <hfinkel <at> anl.gov> writes:> > Do you require long-term cross-release ABI and/or API stability > from the C API that you're using? Do these > other projects?For the record, in llvmlite and Numba we don't require C API stability for two reasons: 1) the C API is not enough for us and we rely on bits of the C++ API 2) we also rely on other details such as textual IR format, which change from release to release anyway. Regards Antoine.