This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Progress on GCC plugins ?
Tom Tromey wrote:
> Bernd> In my view, plugins will bitrot quickly as GCC's interface
> Bernd> changes; and they won't even help with the learning curve -
> Bernd> does anyone believe for a second you won't have to understand
> Bernd> compiler internals to write a plugin?
>
> Plugins are about deployment, not development. They don't make
> writing the code much simpler. That is why we can argue that the risk
> they pose is small: they don't make it significantly simpler to make a
> proprietary GCC.
>
In my situation this point is right on the mark. I follow with a
concrete example.
My project: "EDoc++", requires a patched version of GCC in order to
perform static analysis of source code. I approached the debian
maintainers list with a debian package for this project to see if they
would include it in the official repositories. It was not accepted and
the reason for that is because it includes another patched version of
GCC which takes up too much disk space. They don't want to accept
these sorts of projects because they all effectively require
duplicates of the same code(GCC). This problem of deployment could be
solved with plugins.
Development for my project would not be overly different with the
plugin framework included. I dont expect to be able to write plugins
without an understanding of the internals of GCC which the plugin is
being written for. What i expect from the framework is simplified,
standard method of deployment for additional GCC "features".
As an overall comment on the issues being discussed i think we should
not deliberately omit features that will be useful to the open source
community just to deny these same features to proprietary developers.
This is just shooting ourselves in the foot in order to do the same to
others. It makes no sense as we are restricting our own progress for a
possible misuse of the feature by others (That is already occurring
anyway).
Brendon.