Posted Oct 6, 2008 17:50 UTC (Mon) by droundy (subscriber, #4559)
In reply to: Plugging into GCC by iabervon
Parent article: Plugging into GCC
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.
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.