This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch 0/3] Header file reduction.
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Bernd Schmidt <bschmidt at redhat dot com>
- Cc: Andrew MacLeod <amacleod at redhat dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 5 Oct 2015 16:10:38 +0200
- Subject: Re: [patch 0/3] Header file reduction.
- Authentication-results: sourceware.org; auth=none
- References: <560DEA79 dot 8050709 at redhat dot com> <56127AA4 dot 9090707 at redhat dot com>
On Mon, Oct 5, 2015 at 3:27 PM, Bernd Schmidt <bschmidt@redhat.com> wrote:
> On 10/02/2015 04:22 AM, Andrew MacLeod wrote:
>>
>> The patches are generated by a pair of tools.
>> * gcc-order-includes goes through the headers and canonically reorders
>> some of our more common/troublesome headers and removes any duplicates.
>> This includes headers which are included by other headers. (ie, obstack.h
>> can be removed as a duplicate if bitmap.h is included already.)
>> * remove-includes is the tool which tries to remove each non-conditional
>> header file and does the real work.
>
>
> Is the bitmap/obstack example really one of a change that is desirable? I
> think if a file uses obstacks then an include of obstack.h is perfectly
> fine, giving us freedom to e.g. change bitmaps not to use obstacks. Given
> that multiple headers include obstack.h, and pretty much everything seems to
> indirectly include bitmap.h anyway, maybe a better change would be to just
> include it always in system.h.
Not system.h please - use coretypes.h if really necessary.
Richard.
>> I'll have a patch shortly to add these and some other useful tools to a
>> header-tools directory in contrib.
>
>
> How soon? It's difficult to meaningfully comment on these patches without
> looking at how they were generated. Two points:
> * diff -c is somewhat unusual and I find diff -u much more readable.
> * Maybe the patches for reordering and removing should be split, also
> for readability and for easier future identification of problems.
>
>
> Bernd
>