On Fri, 14 Nov 2008, Brian Dessent wrote: > "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.
Is there some reason there couldn't be one DLL for the code shared between all languages and separate DLLs with each language's front end code? So a plugin that only plugs in to the language-independent code would only need the common DLL, and only plugins for front ends would need that front end's DLL. cc1 would load just the two DLLs for C and for shared code, not all of them. -- Joseph S. Myers [EMAIL PROTECTED]
