Ian Lance Taylor writes: > Andrew Haley <[EMAIL PROTECTED]> writes: > > > Ian Lance Taylor writes: > > > Andrew Haley <[EMAIL PROTECTED]> writes: > > > > > > > > Most new gcc back-ends are private, so I don't buy that part of the > > > > > argument. And in any case nobody is talking about plug-ins for gcc > > > > > backends. We're talking about plugins at the tree/GIMPLE level. > > > > > > > > Yeah, I know. I'm thinking about proprietary compilers (not just > > > > back-ends, optimization passes) bolted on to a gcc front-end to get > > > > Linux compatibility. > > > > > > As we've discussed previously, we are already seeing that without > > > plugins: GCCfss. Sun took gcc's frontend and attached it to their > > > proprietary backend. So in my view introducing plugins will not make > > > a substantive difference here. > > > > Well, yeah, but no-one ever said it wouldn't be possible without > > plugins. > > I'm sorry, I've lost the sense of the argument here. I thought you > were arguing that plugins would make this more likely. I'm saying > that it's already happening, and that it's not noticeably easier > with plugins. So can you repeat your point?
Ah, OK. I think that it will be noticeably easier with plugins. If the plugin architecture really doesn't make it easier, my point falls. > > > > > When I was in the business of convincing people to pay for gcc > > > > > work, I had a laundry list of general gcc improvements to sell. I > > > > > was never able to get a dime except for target specific > > > > > improvements. A plugin architecture would not make any difference > > > > > to that kind of work. > > > > > > > > No, but it might mean that entire gcc ports go away, as people who > > > > already have in-house compilers use them with a gcc front-end for > > > > Linux ports, rather than funding gcc ports. > > > > > > But as you know, most gcc ports are never contributed anyhow. > > > > Sure, but they are still free software: if the compiler gets > > distributed, so does its source code. Of couse, assigning copyright > > to FSF is nice, but freedom is much more important. > > If I follow this, it seems that you are saying that if we have > plugins, some people will choose to use them to get a gcc frontend > for a proprietary compiler rather than doing a gcc port. I'm > sorry, I don't buy this at all. Again, people can already do this, > and adding plugins does not make it substantially easier. Well, that's where we differ. I don't at all understand how adding plugins won't make it very much easier. It seems obvious to me that if there is a reasonably well-defined plugin architecture it will be vastly easier to export data from gcc's front-ends to a proprietary compiler. It is entirely beyond my understanding why this isn't also obvious to you. > > > Ports that people hire Red Hat to do are contributed, but I can > > > easily count six gcc ports I've seen myself that were never > > > contributed. > > > > > So again I don't see a substantive difference here. > > > > I guess it depends on what you mean by "substantive". As I said, > > I suspect that if it were easier to decouple the gcc front-end > > from the back-end and to maintain the resulting compiler, there > > would be fewer free compilers. And no, neither of us can prove > > it without doing the experiment. I insist, however, that when it > > comes to a change that potentially reduces freedom, the burden of > > proof -- or at least of evidence -- is on those wanting to make > > the change. > > I'm very sorry to hear you take that position. I think you are > letting an unlikely fear sacrifice a clear benefit. > > I have a different fear: that gcc will become increasing > irrelevant, as more and more new programmers learn to work on > alternative free compilers instead. That is neutral with regard to > freedom, but it will tend to lose the many years of experience > which have been put into gcc. In my view, if we can't even get > ourselves together to permit something as simple as plugins with an > unstable API, then we deserve to lose. OK. Well, that's your view. I don't believe that the presence or absence of plugins will make one iota of differebce to mainstream use of gcc. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903