Re: [RFC] Fight dependencies in C front end on middle-end include files

[Steven Bosscher <stevenb dot gcc at gmail dot com>]

On Sun, May 16, 2010 at 11:47 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Sat, May 15, 2010 at 10:06 PM, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
>> On Sat, May 15, 2010 at 7:15 PM, Diego Novillo <dnovillo@google.com> wrote:
>>> On Sat, May 15, 2010 at 11:48, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
>>>
>>>> As part of an effort to make GCC more modular, we will have to figure
>>>> out what really depends on what, to make sure we can properly define
>>>> the boundaries of modules and move code where it belongs. For example,
>>>> a front end should not have to know about gimple except at the
>>>> interface with the middle-end, a front end should not have to know
>>>> about RTL at all. But it does need to know about target hooks, etc.
>>>
>>> Agreed. ?Along these lines, how about making header files hermetic so
>>> that they can be included independently of other header files?
>>
>> Yes, that is the plan. First I want to have the front ends reasonably
>> "clean" and I'll clean up things that I run into while working on the
>> front ends first. Next, I want to remove all #include's from header
>> files. The last step would be to make all headers hermetic, but that's
>> going to be a bit more work...
>>
>>
>>>?For instance,
>>>
>>>> +#ifndef GCC_VECIR_H
>>>> +#define GCC_VECIR_H
>>>> +
>>>> +#ifndef GCC_CORETYPES_H
>>>> +#error "vecir.h must be included after coretypes.h"
>>>> +#endif
>>>
>>> Here, I'd just include vec.h as well as coretypes.h. ?Which in turns
>>> means that this becomes the only interface needed to be included from
>>> files that want to handle collections of IR elements.
>>
>> Yes, that is also planned for follow-ups.
>
> Though I'd prefer to have
>
> #include "coretypes.h"
>
> in vecir.h instead.

I think this is not the right way to go. IMHO headers should not
include headers as a matter of principle.

Ciao!
Steven