| |||||||||||||
Plugging into GCCPlugging into GCCPosted Oct 6, 2008 16:50 UTC (Mon) by iabervon (subscriber, #722)Parent article: Plugging into GCC
I'm a bit surprised that nobody's patched in a plugin API in the past year. It is unquestionably legal for somebody to fork GCC and add support for a plugin architecture of their own design. And plugins would be derived from the plugin architecture, and need to be compatible with the license given for it, not for GCC in general. It wouldn't matter too much whether the fork would become the official version, since it would be the version of choice for people doing compiler research. It would also have a reasonable chance of overtaking the official fork if it was an easier environment for useful optimizations than the GCC mainline, like egcs overtook the main branch a while ago.
The core point of free software is that users can work together to work around a software provider who refuses to make the software serve the needs of the users. This applies even if the provider is the FSF and the provider's motivation is supporting the larger free software agenda.
(Log in to post comments)
Plugging into GCC Posted Oct 6, 2008 17:50 UTC (Mon) by droundy (subscriber, #4559) [Link]
I imagine the issue is that of ongoing support. If the main gcc developers don't work on the patched plugin-gcc, it's quickly going to fall behind on features. And any sort of plugin interface seems likely to be extremely invasive, so porting the plugin patches over to newer gcc's most likely wouldn't be feasible in the long term.
Plugging into GCC Posted Oct 6, 2008 18:16 UTC (Mon) by iabervon (subscriber, #722) [Link]
For a lot of things, falling behind on features would be okay for plugin users, because they're often doing things where new features don't matter. (A lot of new features apply only to code generation, so plugins that don't generate code don't care; likewise new language front ends and support code for them aren't important for plugins designed for use with a particular language.)
Furthermore, I remember a lot of main gcc developers being more pragmatic than RMS, so it's likely that, if the plugin architecture used were more suitable for the features they want to write than the mainline code is, they'd actually work on the plugin fork instead (or first, and cross-port their finished feature). I remember hearing that one reason the new register allocator was a huge feature was that it required reorganizing a lot of code that was kept not abstracted in part to avoid making it easy to have plugins.
Plugging into GCC Posted Oct 6, 2008 20:42 UTC (Mon) by nix (subscriber, #2304) [Link]
In practice, GCC has enough weird quirks, even now, that the only way a
fork of GCC is going to take over from GCC itself is if it attracts a lot of the GCC developers (like egcs did). And if it does that, is it really a fork?
Plugging into GCC Posted Oct 6, 2008 23:36 UTC (Mon) by iabervon (subscriber, #722) [Link]
Well, it would be a fork in that it wouldn't necessarily follow the FSF's intentions for direction. For example, a version that supported plugins written to an API that isn't derived from gcc and is BSD-licensed (and could be supported by icc, etc) could become the de facto current branch on technical merit (if it eliminated a lot of the weird quirks from what a significant class of developers had to deal with), despite the fact that this result is exactly what the FSF wants to avoid.
|
|||||||||||||