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
Chris Lattner wrote:> 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.Perhaps, but it's a barrier for those who actually want to use LLVM's JIT. We'd love to keep up with the latest versions of LLVM, but stuff just keeps breaking and sometimes features are just deleted. For example, it used to be possible easily to turn on and off asm dumping, but it isn't any more. Andrew.
On Apr 30, 2009, at 11:27 AM, Andrew Haley wrote:> Chris Lattner wrote: >> 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. > > Perhaps, but it's a barrier for those who actually want to use > LLVM's JIT. > We'd love to keep up with the latest versions of LLVM, but stuff > just keeps > breaking and sometimes features are just deleted. For example, it > used > to be possible easily to turn on and off asm dumping, but it isn't > any more.That's not true. It's just the option name was changed. The option was added initially to facilitate debugging, but people somehow treats it as a feature. That's fine. That just encourage users to get involved with the community. Evan> > Andrew. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev