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.
