Tom Tromey wrote:
"Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> And then, once the underlying problem is addressed and we
Alexandre> have an API that is usable by regular users, maybe we will
Alexandre> find out that we don't need plugins, after all.
Plugins are about deployment, not development.
Plugins make it possible to redistribute useful things which are not
in GCC. They don't -- and as you rightly point out, can't -- make it
simpler to actually develop these things.
The canonical example, which has been covered many times, is a pass
that does extra checking for a large program (e.g., Mozilla).
There are a lot of checks that could be implemented as plugins to
benefit Mozilla and other projects. For future Mozilla development
certain features that we are looking at are not feasible in C++ until
the compiler can help with enforcing correct API usage. It would be
extremely awesome to be able to utilize GCC internals for static
analysis and source refactoring. Currently that isn't realistic as these
features do not belong in the GCC mainline and distributing a gcc fork
would be very burdensome.
Plugins would also encourage projects such as Mozilla to contribute to
gcc to implement various backend improvements to make various plugins
possible. I think GCC could gain some "accidental" contributors this way.
i believe that this would also have an additional effect of making GCC
the strongly suggested compiler for development as it would be able to
provide development benefits not (yet?) available in most compilers.
LD_PRELOAD would work just as well as having gcc directly support
plugins, provided that certain internal things are never made
file-local. Someone could write a helper library to make it
relatively simple to hook in. But... I looked at this recently, and
since gcc is not linked with -rdynamic, it is a non-starter.
Tom, I don't know much about linkers and LD_PRELOAD. Would making
LD_PRELOAD work be easier than making an unstable plugin API?
Taras
