Plugging into GCC

Posted Oct 3, 2008 15:37 UTC (Fri) by bronson (subscriber, #4806)
Parent article: Plugging into GCC

> Another possibility is to take a page from the Linux kernel's book and keep the plugin API unstable.

This would only work if the ultimate intent for plugin writers is to upstream their plugins and have the GCC devs eventually take over maintenance.

If the GCC devs are up for this, I think it sounds like a phenomenal idea!

Plugging into GCC

Posted Oct 3, 2008 20:26 UTC (Fri) by ikm (guest, #493) [Link] (2 responses)

Exactly! Unless a plugin is incorporated upstream, it doesn't matter whether it is GPLed or proprietary the authors would have to routinely update for each new version, and the users would have to update to these versions each time they update to a newer gcc.

And given the conservative approach of the FSF, I'd doubt many plugins would end up upstream. Well, maybe it's just me.

Anyway, the idea of breaking the API solely for the sake of doing so feels ill-intended and just plain wrong. Maybe sometimes it's better to just relax, let go and assume that the world is not really *that* hostile? :)

Plugging into GCC

Posted Oct 4, 2008 8:44 UTC (Sat) by drag (guest, #31333) [Link] (1 responses)

If people wanted to make a proprietary plugin to GCC then they would of already done so.

The GCC suite is free software last time I checked, so modifying the GCC source code to communicate with a proprietary hunk of software is something that they can already certainly do. Just as long as they release the GCC portion of the patch under the GPL there is nothing stopping them from having it work with something closed source.

The question is all about the cost

Posted Oct 5, 2008 7:50 UTC (Sun) by khim (subscriber, #9252) [Link]

Not so simple. One company should introduce (and support) such modified version of GCC and another unrelated company can then produce proprietary plugin (if they will be related court can declare both the part of the cartel created to circumvent the GCC). And this makes the whole scheme totally unrealistic: second company is doing it's business on the basis of code produced by someone who has NO obligations to that company AND is not supported upstream... Very flacky foundations. And GCC developers will not tolerate such abuse: where kernel developers are in unenvious situation where they can punish abusers only at the expense of users (there are no way to use nVidia cards except by using binary module) GCC works just fine without any such proprietary blobs...

Sorry but to distribute proprietary plugin to GCC today is not hard. It's very hard... FSF will like to keep it this way - what's so strange about this?