From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22116 invoked by alias); 14 Apr 2010 21:02:17 -0000 Received: (qmail 21899 invoked by uid 22791); 14 Apr 2010 21:02:15 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,SPF_FAIL X-Spam-Check-By: sourceware.org Received: from mx20.gnu.org (HELO mx20.gnu.org) (199.232.41.8) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 14 Apr 2010 21:02:10 +0000 Received: from mail.codesourcery.com ([38.113.113.100]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1O29iq-0002EW-E1 for gcc@gcc.gnu.org; Wed, 14 Apr 2010 17:02:08 -0400 Received: (qmail 32392 invoked from network); 14 Apr 2010 21:02:06 -0000 Received: from unknown (HELO localhost) (froydnj@127.0.0.2) by mail.codesourcery.com with ESMTPA; 14 Apr 2010 21:02:06 -0000 Date: Wed, 14 Apr 2010 21:04:00 -0000 From: Nathan Froyd To: Basile Starynkevitch Cc: Toon Moene , Diego Novillo , Manuel =?iso-8859-1?B?TPNwZXotSWLh8WV6?= , Steven Bosscher , Grigori Fursin , Dorit Nuzman , gcc@gcc.gnu.org Subject: Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop) Message-ID: <20100414210206.GV540@codesourcery.com> References: <003b01cadbde$21913eb0$64b3bc10$@com> <20100414154431.GR540@codesourcery.com> <4BC609AA.7080503@moene.org> <4BC61C34.7070106@starynkevitch.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BC61C34.7070106@starynkevitch.net> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-detected-operating-system: by mx20.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-IsSubscribed: yes 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 X-SW-Source: 2010-04/txt/msg00354.txt.bz2 On Wed, Apr 14, 2010 at 09:49:08PM +0200, Basile Starynkevitch wrote: > Toon Moene wrote: >> >> Mutatis mutandis, the same goes for GCC: There might be too many >> hurdles to use GCC in academia. > > This is probably true, however, the plugin ability of the just released > GCC 4.5 (or is it released tomorrow) helps probably significantly. > > Academics (even people working in technological research institutes like > me) will probably be more able to practically contribute to GCC thru the > plugin interface. It brings two minor points: a somehow defined plugin > API (which is a sane "bottleneck" to the enormity of GCC code), and the > ability to practically publish code without transfering copyright to FSF > (in the previous situation, the only way to avoid that was to create a > specific GPLv3 fork of GCC; in practice it is too expensive in labor for > academia). I appreciate the point about the difficulty of copyright transference in an academic environment, having gone through such difficulties myself. But I think you are confusing "using GCC as a base for your research activities" and "getting the results of that research accepted upstream". I think plugins help in the first category insofar as they force GCC to clearly define interface boundaries. But they have little effect concerning the second category. Perhaps people will be able to make their code more widely available: the plugin interface will likely be relatively stable (I realize this is not guaranteed) and people can therefore release easily compilable packages. Before, you would be forced to distribute (and maintain!) patch files that may need significant changes from release to release. -Nathan