[EMAIL PROTECTED] (Richard Kenner) writes: > > I don't believe this is a strong argument. My contention is, and has > > always been, that GCC is _already_ trivial to integrate into a > > proprietary compiler. There is at least one compiler I know that does this. > > I believe that any such compiler would violate the GPL. But I also believe > it's not in the best interest of the FSF to litigate that matter if the > linkage between the compiler is anything other than linked in a single > executable. Therefore, I think it's important for us to make it as > technically hard as possible for people to do such a linkage by readin and > writing tree or communicating as different libraries or DLLs. I'm very > much against any sort of "plug in" precisely for this reason.
We can make it as technically hard as possible, but it's way too late to make it technically hard. In fact, it's easy. You have to write some code to translate from tree to your proprietary IR, and then you have to plug that code into passes.c. If gcc supports plugins, then all we've eliminated is the need to plug that code into passes.c. But that is the easiest part of the job. Adding plugins is not going to require us to support a stable tree interface or anything along those lines; if it did, I would oppose that. So this seems to me to be a very weak argument against plugins. Adding plugins does not make it noticeably easier to integrate gcc's frontend with a proprietary compiler. And adding plugins would not change the issue of whether such a combination violated the GPL. Do you disagree with this assessment? I think it's quite important for gcc's long-term health to permit and even encourage academic researchers and students to use it. And I see plugins as directly supporting that goal. Note that I don't see any problem with requiring (or attempting to require) that any plugin be covered by the GPL. So from my perspective the downside of plugins is very small, and the upside is very large. Ian
