This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

new plugin events


I am changing the subject to new plugin events. It used to be: PLUGIN_PRAGMAS event

The discussion has nothing to do with pragma inside plugins anymore.

Diego Novillo wrote:
On Fri, Nov 6, 2009 at 12:56, Basile STARYNKEVITCH
<basile@starynkevitch.net> wrote:

What is the criteria for adding them or for rejecting them as theoretical?

That you have a specific plugin making concrete use of them. A theoretical event would be one that is only added just in case a future plugin may have a use for it.

I don't have an internal plugin branch.  I am working off of a 4.4
compiler with backported plugin support.  The events I need to add are
all for dehydra's use.  I need to add an event for when the parser
finishes recognizing a DECL (the PR I pointed to earlier) and also I
need some pre-processor events for allowing dehydra to expose things
like #define and #include to user javascript code.

I fully agree and I probably will use myself these events within 2 or 3 years, but then the ICI effort seems to be exactly in the same position. [They have a branch somewhere demonstration all their needs - this is code, not theory]

But there is a chichen & egg issue still here. So, to add a new event, people (outside of the first circle of GCC like Diego Novillo & Richard Guenther & perhaps Rafael Espindola, that is outside of the "reviewer" set) need to first code their plugin and patch their GCC trunk, and then submit a patch.

I repeat that adding several plugin events (I mean extending the enum plugin_event in gcc-plugins.h) is very inocolous, provided the event is not appearing in some call to invoke_plugin_callbacks which is executed many times.

I also am convinced that GCC need more plugins, it should not be afraid of them (GCC should be afraid of competitor compilers, not of plugins). Hence the GCC community should help the ICI community to make ICI a big plugin itself for the next gcc-4.5. And that help means accepting new events, if the ICI people need them. Of course, ICI should quickly define the set of events they need. But they should first push their new events into the GCC trunk, and then patch their existing ICI code to use them.

I really insist that the position "events are only accepted if there exist a mature & running plugin needing them" is not sustainable.

And I also insist that having 4.5 with a bigger set of plugins is important. I mean 4.5, not 4.6. The 4.5 compiler will still be used a lot in 2013!

I don't understand why adding new plugin events is so difficult for people outside the first circle.
The first circle should trust a bit more outsiders wanting to code plugins.

If some ICI guy says I need this and this event, we should listen & discuss his patch!
[Same goes for me]


Regards.



-- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} ***


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]