On Tue, Jun 9, 2015 at 2:32 PM, Andrew MacLeod wrote:
> On 06/09/2015 03:56 AM, Richard Biener wrote:
>>
>> On Mon, Jun 8, 2015 at 7:52 PM, Andrew MacLeod
>> wrote:
>>>
>>>
>>> the gcc source files need to see the internal bits in plugin.h, as well
>>> as
>>> the common decls in gcc-plugin.h. So
On 06/09/2015 03:56 AM, Richard Biener wrote:
On Mon, Jun 8, 2015 at 7:52 PM, Andrew MacLeod wrote:
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
On Mon, Jun 8, 2015 at 7:52 PM, Andrew MacLeod wrote:
> On 06/08/2015 09:32 AM, Richard Biener wrote:
>>
>> On Mon, Jun 8, 2015 at 2:07 PM, Andrew MacLeod
>> wrote:
>>>
>>> During the original flattening process I decided to use gcc-plugin.h as
>>> the
>>> kitchen sink for all includes that plugi
On 06/08/2015 09:32 AM, Richard Biener wrote:
On Mon, Jun 8, 2015 at 2:07 PM, Andrew MacLeod 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
On Mon, Jun 8, 2015 at 2:07 PM, Andrew MacLeod 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 f
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 intern
