Re: Plug-ins on Windows

[Kyle Girard <kyle at kdmanalytics dot com>]

> The main utility of plugins is that they make developing, testing and
> deploying modifications to gcc easier.  I don't think that MS windows users
> will miss too much if they can't dynamically load the plugins, as long
> as their sysadmin can provide them with a linked-in version - the sysadmin
> might actually be happier about the greater control, as plugins are
> potential virus/trojan vectors.
> It makes sense to write a plugin in such a way that it can alternatively
> be used as a GCC patch - in the sense that you add the code alongside
> the main gcc code and it gets linked in.
> Maybe we should create an interface for linked-in plugin code, i.e.
> arrays of plugin names and their plugin_init function so that they can
> be activated with a matching -fplugin=built-in:NAME (or propose a different
> syntax if you think of a better one) and get passed any plugin options
> like a dynamically loaded one would.
> 

A generic linked-in plugin ability would definitely solve my
plugin-on-windows problem.  From what I've been reading on this list it
looks like I'm going to have to do some sort of similar hack to gcc to
get my plugin working on windows at least in the short term.  

Is there so little demand for dynamically loaded plugin on windows
platform that a generic linked-in plugin framework could be how plugins
are supported on windows?  Just drop the plugin source and a config of
some sort in a directory of the main gcc build and it's pulled in
auto-magically? 

Kyle