I'm working on a plugin architecture for GCC. The idea is to provide an interface through which shared libraries can contribute components (plugins) that can cooperate to deliver services to GCC.
Each plugin is given a simple lifecycle model and is allowed to determine its initialisation parameters from a free form XML specification - allowing for the initialisation complexity suitable for scripting, for example.
Plugins communicate with each other via extension points which allow the plugins to share behaviours and listen to events, etc.
The idea is that rather than having a plethora of different GCC branches, we may get a simpler, smaller GCC into which code libraries are selected at runtime, allowing GCC modifications to live outside of GCC. Presently, (I think, from what little I know:) ) getting code accepted in the mainline GCC is not easy. A plugin architecture would make this mostly unneccessary for many projects. Users could try out new plugins without having to install a whole new suite and could pick and choose plugins that suit them in much the same way that nearly every Eclipse user has their own set of favourite plugins.
Before this I had embedded a JavaScript engine (SpiderMonkey) into GCC to allow easy experimentation with various behaviours in GCC and allowing exploration of the data structures in GCC. It allowed significant functionality to be added without having to recompile GCC and being a scripting language allowed arbitrary complexity when extending GCC.
JavaScript bindings were created only on demand ensuring that GCC's performance wasn't adversely affected.
Being a scripted, GCC data structures were presented in an object oriented way without having to concern oneself with the complexities of memory management and odd macros here, there and everywhere. One could make small modifications in a few easy lines of script without having to dig deep into GCC to do it, so it lowered the bar to getting involved in GCC.
The JavaScript embedding has been shelved until a language agnostic architecture is in place (possibly the plugin idea above). It will then be rebuilt using that new architecture.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm working on a plugin architecture for GCC. The idea is to provide an interface through which shared libraries can contribute components (plugins) that can cooperate to deliver services to GCC.
Each plugin is given a simple lifecycle model and is allowed to determine its initialisation parameters from a free form XML specification - allowing for the initialisation complexity suitable for scripting, for example.
Plugins communicate with each other via extension points which allow the plugins to share behaviours and listen to events, etc.
The idea is that rather than having a plethora of different GCC branches, we may get a simpler, smaller GCC into which code libraries are selected at runtime, allowing GCC modifications to live outside of GCC. Presently, (I think, from what little I know:) ) getting code accepted in the mainline GCC is not easy. A plugin architecture would make this mostly unneccessary for many projects. Users could try out new plugins without having to install a whole new suite and could pick and choose plugins that suit them in much the same way that nearly every Eclipse user has their own set of favourite plugins.
Before this I had embedded a JavaScript engine (SpiderMonkey) into GCC to allow easy experimentation with various behaviours in GCC and allowing exploration of the data structures in GCC. It allowed significant functionality to be added without having to recompile GCC and being a scripting language allowed arbitrary complexity when extending GCC.
JavaScript bindings were created only on demand ensuring that GCC's performance wasn't adversely affected.
Being a scripted, GCC data structures were presented in an object oriented way without having to concern oneself with the complexities of memory management and odd macros here, there and everywhere. One could make small modifications in a few easy lines of script without having to dig deep into GCC to do it, so it lowered the bar to getting involved in GCC.
The JavaScript embedding has been shelved until a language agnostic architecture is in place (possibly the plugin idea above). It will then be rebuilt using that new architecture.