Basile STARYNKEVITCH <bas...@starynkevitch.net> writes: > Ian Lance Taylor wrote: >> We should add hooks as we find plugins that need them. Simply adding >> a laundry list of hooks that we think might be needed will most likely >> cause us to overdesign. We know that we can write interesting plugins >> today, so we're not missing anything critical. > > I believe there is a strong chicken & egg issue here. Ian is > suggesting that hooks should be added only when an existing plugin > would need them, but I believe that on the contrary plugins won't > appear if they don't have a sufficient set of hooks.
I didn't mean that the plugin had to exist, I meant that there had to be a real plugin in view which needed them, not a purely theoretical need. > I have a concrete example here: plugin-specific pragmas (see > PLUGIN_REGISTER_PRAGMA on http://gcc.gnu.org/wiki/plugin%20hook for > details) Sure, we clearly need some way for plugins to manage pragmas and attributes. This doesn't require much support. I would first ask whether attributes are enough, but it wouldn't bother me to have support for pragmas. > * propose a simple patch to add the PLUGIN_REGISTER_PRAGMA event now? Do this. > should I propose a patch for registering pragmas for (and from inside) > a plugin, given the motivations discussed above? Is that acceptable in > the current stage3 state of the trunk? I believe that such a patch is acceptable in stage 3. On the other hand, skimming your list of hooks, I really question the need for, e.g., REPLACE_PASS_MANAGER. I would want to see a real use case there before adding such a hook. For something like PLUGIN_ADD_CPP_MACROS, the need is clear, but I think it's an open question we should add a hook or whether the plugin should just call cpp_define. A hook means that we promise to always have a way to do this in case cpp_define changes. How do we decide when to add that kind of thing to the plugin interface and when to simply require the plugin to invoke gcc functions directly? Ian
