On Mon, Jun 8, 2015 at 7:52 PM, Andrew MacLeod <amacl...@redhat.com> wrote: > On 06/08/2015 09:32 AM, Richard Biener wrote: >> >> On Mon, Jun 8, 2015 at 2:07 PM, Andrew MacLeod <amacl...@redhat.com> >> wrote: >>> >>> During the original flattening process I decided to use gcc-plugin.h as >>> the >>> kitchen sink for all includes that plugins might need. I think this has >>> worked well for plugins, drastically reducing their dependency on gcc >>> internal header file structure. >>> >>> What I didn't realize was that gcc's internal header (plugin.h) also >>> includes gcc-plugin.h. This means that every file which may need to do >>> something for plugins ends up indirectly including the gcc world again >>> :-P >>> >>> Easy fix. (ha). This patch leaves all the #includes in gcc-plugin.h >>> making >>> the change transparent to plugins. All the remaining declarations and >>> such >>> are moved into a new file gcc-plugin-common.h. Both gcc-plugin.h and >>> gcc's >>> internal header plugin.h now include this common file. >>> >>> The effect is that gcc's source files no longer get anything but the >>> required plugin info. Great.. Except there were a few files which were >>> apparently picking up some required headers from gcc-plugins.h :-P >>> This >>> patch also adds the required headers to those source files. >>> >>> Compiles on x86_64-unknown-linux-gnu with no new regressions. Also >>> compiles >>> across all targets in config-list.mk. OK for trunk? >> >> Err - why not simply remove the gcc-plugin.h include from plugin.h and >> instead >> include plugin.h from gcc-plugin.h? >> >> > > the gcc source files need to see the internal bits in plugin.h, as well as > the common decls in gcc-plugin.h. So we could change the includes as you > suggest, but we'd have to copy all the decls from gcc-inlcude.h to plugin.h > so the gcc functions can see them. And then the plugins would be exposed to > all the internal APIs and decls present in plugins.h
plugins are exposed to all internals of GCC anyway. gcc-plugin.h should really just be a #include kitchen-sink. > Adding the 3rd file which contains all the common decls between both sides > is the only way to isolate both. If you were OK with exposing the > internal parts of plugin.h to plugin clients I could do that. Yes. > Im presuming > we didnt want to do that and thats why there were 2 files to start with. No, gcc-plugin.h was introduced to make the set of includes required for plugins "stable". Richard. > I > hijacked the external interface in gcc-plugin.h file to provide all the > includes when instead the right thing would have been to probably create a > new in the first place. > > Andrew > > >
