From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117235 invoked by alias); 13 Mar 2017 17:12:49 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 117221 invoked by uid 89); 13 Mar 2017 17:12:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=pet, wow, volunteer, wow! 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 ESMTP; Mon, 13 Mar 2017 17:12:47 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 29FC8C0A9CDB for ; Mon, 13 Mar 2017 17:12:48 +0000 (UTC) Received: from snowball.redhat.com (ovpn-117-23.ams2.redhat.com [10.36.117.23]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v2DHCkRP027183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 13 Mar 2017 13:12:47 -0400 From: Nick Clifton To: gcc@gcc.gnu.org Subject: RFC: Treat plugins as first class citizens Date: Mon, 13 Mar 2017 17:12:00 -0000 Message-ID: <87vardgkxe.fsf@redhat.com> MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg00058.txt.bz2 Hi Guys, I was thinking that it would be nice to make plugins a "first-class citizen" in the gcc world by having a proper directory structure and integration into the rest of gcc. For example: gcc/plugins <-- Everything plugin-y starts here gcc/plugins/Make-lang.in <-- Makefile fragment. gcc/plugins/src <-- Maybe move gcc/plugins.[c|h|def] here ? gcc/plugins/doc <-- Actual documentation, wow! gcc/plugins/testsuite <-- Tests for the plugins and their integration into gcc gcc/plugins/config <-- Subdirectories of this directory contain each real plugin gcc/plugins/config/annobin <-- For example, this is where my pet plugin would go Plus there could be an official plugins maintainer. (I am willing to volunteer, so is Aldy Hernandez). The documentation would be compiled along with the rest of gcc's documentation and the testsuite would be run as part of gcc's normal testing process. Ideally I would also like to see plugin test failures be considered as blockers for new releases, but that is something for the future. So, what do you think ? Should I create a patch and submit it for official review ? Cheers Nick