"Joseph S. Myers" wrote: > As I understand it, there is an alternative - put all the shared code in a > DLL on Windows if configuring with plugins enabled, and link both the > plugins and cc1, cc1plus etc. with that DLL. If people wish to enable
The problem with that approach is that people have so far said they want access to every aspect of the compiler from within the plugin, i.e. to poke and prod at the full symbol table, without being tied down by a limited, designated access route of a plugin API. This means you'd have to move essentially everything into this mega-DLL, leaving cc1 and friends as merely stubs that set a flag and then call into the DLL never to return, since anything left in cc1 would not be accessible from the plugin. That would present a problem to packagers. Since the code for all the language backends would be in this one mega-DLL, it would be impossible to install one language's compiler without installing all of them. Sure, you could still split it up into separate packages for the sake of the other runtime library support components and headers, but the user would still be paying the price in terms of disk and memory consumption of this mega-DLL that supports all languages when only using one of them. Of course this would only happen if you enabled plugin support, but from the standpoint of the packager/disto role you wouldn't want to ship a plugin-disabled gcc because then your users would have to go to the trouble of building gcc themselves from source if they wanted to try a plugin. Not having to do that is supposed to be one of the major reasons for developing plugins in the first place. So you end up with all users paying the cost of the entire compiler suite condensed into this monolithic chunk even if only a small fraction of users are interested in trying a plugin. Brian
