This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Progress on GCC plugins ?


>>>>> "Bernd" == Bernd Schmidt <bernds_cb1@t-online.de> writes:

Bernd> I must admit I don't understand the upside.  I've always thought of
Bernd> plugins as something proprietary programs need because their source
Bernd> isn't open.

Everybody explained about the existing free software that has plugins.
But, I thought I'd mention a few use cases for plugins.

The biggest benefit of a plugin system is that you can add things to
the compiler without requiring all your users to build their own
compiler.

E.g., Mozilla developers have said before (even earlier in this
thread) that they would like to be able to run Mozilla-specific
analysis passes over their code, say before checkin.  Probably this
consists of a bunch of warning checks that are suitable for Mozilla
but not suitable for inclusion in GCC.  With a plugin system they have
the option of providing "Mozilla GCC plugin for Fedora 9", or
whatever, and avoiding the mess of "to build Mozilla first you have to
build GCC with patch X".

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.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]