Basile STARYNKEVITCH wrote: > (a meta question: do we need to reply-to all, or should the gcc@ list be > enough to discuss plugins, and the only destination of this interesting > discussion?).
Reply-to-all is the common standard on the list. If you don't want a personal copy then set the "Reply-to:" header in your message to the list address and you won't be included in CC by most email clients when someone does reply-to-all. > I'm not sure that pre-compiled headers (pch) should even work with > plugins. The reasonable solution is to disable them when any plugin is > used (what should happen if plugins are not used when the pch is > generated, but used when it is reloaded or viceversa; I don't know if > this situation is hard to detect. Likewise, what should happen when the > compilation of the header & the compilation of the source including the > pch both dlopen-ed a different variant of the "same" plugin?). At least, > having pch working with plugins should be postponed after the first > approved (i.e. merged into the trunk) plugin imlementation. There's already an existing requirement that the compiler options used when precompiling the .gch must match or be compatible with those used when using the .gch, so in essence the above is already forbidden by the fact that adding or removing -fplugin= would render the .gch unusable. I seem to recall that the .gch file records the entire set of options used when it was built and gcc refuses to consider the file if it does not exactly match, however the documentation seems to imply that only certain options are automatically checked/rejected while others are the responsibility of the user to enforce: <http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html>. Brian
