search for: solidif

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

...s 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 i...

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

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