plugin hooks for plugin-provided builtins?

Diego Novillo dnovillo@google.com
Tue Sep 14 14:46:00 GMT 2010


On Tue, Sep 14, 2010 at 09:36, Basile Starynkevitch
<basile@starynkevitch.net> wrote:

> I was thinking of adding a new plugin hook for builtins.

We need to have a good use case before adding any more plugin hooks.
In the case of this proposal, you also need a fixed code and a class
for the builtins to work.

In general, plugin support is in a state of flux, because we still
have not agreed on a general set of APIs that we want to export to
plugins.

Instead of thinking of new places to add callbacks, I would like to
take a couple of steps back and solve the API issue.  What should
plugins be allowed to see?  Currently, we have an arbitrary collection
of internal header files that we just expose to 3rd parties.  This is
sub-optimal.  I would like to have a limited set of headers that
contain exactly the functions and data structures that we allow plugin
code to interact with.

I believe that this problem will be largely solved when we make more
progress in solving the internal modularity problem.  So, I think we
still have to solve that problem before we can think about the
interfaces we want to export.

Plugin hooks should only be added when an actual need arises.  Adding
hooks for the sake of adding hooks is not a good way to evolve this
functionality.


Diego.



More information about the Gcc mailing list