Re: gcc extensibility

[nisse at lysator dot liu dot se (Niels Möller)]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

> It is a false equality.  The needs of plugins authors are not necessarily
> the same as the need of GCC development itself.

I'm not so sure of that. To be concrete, can you give some examples of
things that a plugin might want to do with an interface to the
tree-abstraction in gcc, which gcc itself would never do? And vice
versa?

The typical needs may be different, but I don't think it's wise to a
priori rule out the possibility of designing, e.g, a tree API, which is
both powerful enough and clean enough to serve well both plugins and the
rest of gcc.

> You really do not want the existence of plugins to hinder (internal)
> evolution of GCC itself.

Agreed. Question is how much interface stability is needed by plugins,
and how often gcc internals must change important interfaces. I would
expect that binary compatibility is not terribly important, i.e., it's
acceptable if plugins sometimes have to be recompiled even for a new
minor release (and we don't want to allow proprietary binary-only
plugins anyway, right?).

Breaking source level compatibility ought to be avoided for minor
releases. But the current situation, where, due to the name mangling, it
seems difficult for a plugin to be compatible even with different
configurations of the *same* minor release of gcc, seems a bit too
inconvenient.

Then I'd also expect that certain interfaces, e.g., the tree interface,
can be a lot more stable than others.

Bottom line: When interface changes in gcc really are needed, then just
do them (preferably in connection with a major release), and plugins
will have to follow.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.