On Mon, 18 Nov 2013, Basile Starynkevitch wrote: > On Mon, 2013-11-18 at 13:17 +0000, Joseph S. Myers wrote: > > On Sun, 17 Nov 2013, Basile Starynkevitch wrote: > > > > > What would be the good way to add such a plugin event to GCC 4.9? > > > > See the cpp_callbacks structure, used to make diagnostics go through GCC's > > diagnostics machinery, for example. I'm not clear why the existing > > callbacks (in particular the file_change one) wouldn't be enough. > > > Thanks for your reply (and your interest to my suggestion). > > I am not sure to understand what you suggest (because I see several ways > to understand it).
I'm suggesting: * You probably don't need to change libcpp at all. Instead, insert your call to invoke_plugin_callbacks inside c-opts.c:cb_file_change. * But if for some reason cb_file_change isn't called at the right time, then create a new function, still inside the c-family code, which calls invoke_plugin_callbacks, and a corresponding cpp_callbacks entry for it, and make one of the c-opts.c functions that sets callbacks fill in the new entry. The key point is that both of those keep libcpp self-contained - you don't need to include plugin headers inside libcpp, because the libcpp client is responsible for registering callbacks with libcpp's callback mechanism, and it's the responsibility of such a callback to call plugins if the libcpp client (GCC in this case) has a plugin mechanism such that a plugin should be called from the callback. > What do you practically suggest? Don't you feel that adding a new plugin > event (PLUGIN_HEADER_FILE) to plugins.def and adding a single call to > invoke_plugin_callbacks much lighter and simpler than having the plugin The point is that this call needs to be in GCC, the client of the libcpp library, not directly in libcpp, the library. -- Joseph S. Myers jos...@codesourcery.com
