On Apr 29, 2009, at 8:39 AM, David Greene wrote:> > This patch changes the LLVM API. We should have a process for > deprecating > obsolete interfaces before removing them entirely. It's a significant > maintenance headache to pull down a new release and fix all of the API > issues along with tracking down new bugs introduced.No, we make no attempt at being API compatible across revs of LLVM. This is a great way to encourage people to contribute their code to the project. If they want to live with their code out of tree, then they have to deal with API breakage. -Chris
On Wednesday 29 April 2009 19:22, Chris Lattner wrote:> On Apr 29, 2009, at 8:39 AM, David Greene wrote: > > This patch changes the LLVM API. We should have a process for > > deprecating > > obsolete interfaces before removing them entirely. It's a significant > > maintenance headache to pull down a new release and fix all of the API > > issues along with tracking down new bugs introduced. > > No, we make no attempt at being API compatible across revs of LLVM.That's a huge mistake going forward if we want to grow the community.> This is a great way to encourage people to contribute their code to > the project. If they want to live with their code out of tree, then > they have to deal with API breakage.It's not about people not contributing code. It's about 3rd party modules that have to interface to LLVM. The LLVM community does not care about the Cray optimizer code. But the Cray optimizer code must use LLVM APIs to translate the Cray IR to LLVM IR. If we can distinguish between "internal" and "external" LLVM APIs that's fine but I suspect each person's definition of "internal" and "external" will vary quite a bit because people interface to LLVM at very different points. -Dave
On Apr 30, 2009, at 9:38 AM, David Greene wrote:> On Wednesday 29 April 2009 19:22, Chris Lattner wrote: >> On Apr 29, 2009, at 8:39 AM, David Greene wrote: >>> This patch changes the LLVM API. We should have a process for >>> deprecating >>> obsolete interfaces before removing them entirely. It's a >>> significant >>> maintenance headache to pull down a new release and fix all of the >>> API >>> issues along with tracking down new bugs introduced. >> >> No, we make no attempt at being API compatible across revs of LLVM. > > That's a huge mistake going forward if we want to grow the community.Perhaps. However, I greatly prefer to make life easier for people who contribute code (by preventing them from having to worry about deprecation etc) than for those who don't. Reducing the barrier to contributing code is a good way (IMO) to encourage contributions and new developers.>> This is a great way to encourage people to contribute their code to >> the project. If they want to live with their code out of tree, then >> they have to deal with API breakage. > > It's not about people not contributing code. It's about 3rd party > modules > that have to interface to LLVM. The LLVM community does not care > about > the Cray optimizer code. But the Cray optimizer code must use LLVM > APIs > to translate the Cray IR to LLVM IR.Understood, Apple also has external code that interfaces to LLVM as well, and it has to be updated as well. I still maintain that we should optimize for encouraging contributions. If you have out of tree code that depends on unstable APIs, you should expect to have to change it to work with new version of LLVM. The only stable API we vend is the C interface bindings. -Chris