Gabriel Dos Reis <g...@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.
