From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35367 invoked by alias); 23 Oct 2015 15:11:49 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 35352 invoked by uid 89); 23 Oct 2015 15:11:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 23 Oct 2015 15:11:48 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 662142634 for ; Fri, 23 Oct 2015 15:11:47 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-196.phx2.redhat.com [10.3.113.196]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t9NFBkwl009437; Fri, 23 Oct 2015 11:11:47 -0400 Subject: Re: [patch 1/3] Header file reduction - backend files. To: Andrew MacLeod , gcc-patches References: <560DEA79.8050709@redhat.com> <560DECE1.5080807@redhat.com> <5629623C.8080308@redhat.com> <5629C912.5050502@redhat.com> <562A2714.5030806@redhat.com> From: Jeff Law Message-ID: <562A4E32.8030508@redhat.com> Date: Fri, 23 Oct 2015 15:15:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <562A2714.5030806@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg02463.txt.bz2 On 10/23/2015 06:24 AM, Andrew MacLeod wrote: > > Hmm. yeah, It was mostly intended to show you what structure you have > and are getting indirectly, not so much indicate that you actually > include things directly twice. It utilizes a common function which > returns unique header files (find_unique_include_list) and just > processes those. A quick tweak should resolve that to just linearly > parse and process. It may not be worth the trouble. There were maybe a half-dozen files with repeated direct includes and they stood out as not being as mechanical as the others (with respect to reviewing the changes). I suspect that in the future it won't happen much, if at all, and we won't be looking at 15k line patches to clean things up. > > It also occurs to me the reason you only found one options.h in the > previous note... show-headers probably didn't know where to look for > your build directory to delve into tm.h. It defaults to ../../build > which is what I use. I will also tweak that to attempt to automatically > find a build directory below ../.. and failing that, have you specify one. Yea, I almost asked about procedures for the tool to find tm.h as it was relatively common for tm.h to include something indirectly and make later stuff redundant. But after a while, I got pretty good at knowing what was in tm.h and how that would effect what headers became redundant as tm.h got included earlier (via target.h). Similarly for optabs.h moving around and making other stuff redundant. Jeff