From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 125907 invoked by alias); 8 Jun 2015 17:52:14 -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 125898 invoked by uid 89); 8 Jun 2015 17:52:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no 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; Mon, 08 Jun 2015 17:52:12 +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 73FC1BBF52; Mon, 8 Jun 2015 17:52:11 +0000 (UTC) Received: from [10.10.53.83] (vpn-53-83.rdu2.redhat.com [10.10.53.83]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t58HqA1x022979; Mon, 8 Jun 2015 13:52:11 -0400 Message-ID: <5575D64A.1020102@redhat.com> Date: Mon, 08 Jun 2015 18:18:00 -0000 From: Andrew MacLeod User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Richard Biener CC: gcc-patches Subject: Re: [patch] Adjust gcc-plugin.h References: <55758574.7070104@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00610.txt.bz2 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 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 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. Im presuming we didnt want to do that and thats why there were 2 files to start with. 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