This is the mail archive of the
mailing list for the GCC project.
Re: gcc extensibility
Gabriel Dos Reis <firstname.lastname@example.org> 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
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
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.
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.