From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24311 invoked by alias); 22 Jun 2009 11:35:32 -0000 Received: (qmail 24300 invoked by uid 22791); 22 Jun 2009 11:35:31 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_62,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-qy0-f194.google.com (HELO mail-qy0-f194.google.com) (209.85.221.194) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 22 Jun 2009 11:35:24 +0000 Received: by qyk32 with SMTP id 32so3643112qyk.0 for ; Mon, 22 Jun 2009 04:35:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.95.194 with SMTP id e2mr3569351vcn.60.1245670522197; Mon, 22 Jun 2009 04:35:22 -0700 (PDT) In-Reply-To: <4A3F6910.8080902@starynkevitch.net> References: <4A3F6910.8080902@starynkevitch.net> Date: Mon, 22 Jun 2009 11:35:00 -0000 Message-ID: <84fc9c000906220435t319cecf9yd2a7673d09784dd5@mail.gmail.com> Subject: Re: plugins directory? From: Richard Guenther To: Basile STARYNKEVITCH Cc: GCC Mailing List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: 2009-06/txt/msg00503.txt.bz2 On Mon, Jun 22, 2009 at 1:20 PM, Basile STARYNKEVITCH wrote: > Hello All, > > This is a discussion complementing > http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01587.html. So plugins here > means GPLv3 licensed GCC plugins. > > First, I believe that progressively, there will be some plugins dedicated= to > the compilation of some major specific free software, mostly for applicat= ion > specific warnings. > For example, it could happen that the Linux kernel community, or KDE/QT > community, or Gnome/GTK community, or Apache community will progressively > develop plugins to help their development. BTW, the treehydra effort from > Mozilla (that is Taras Glek) is illustrative of my intuition. > > I am alone in having this belief (that application specific GCC plugins > would appear, mostly for static analysis or better diagnostic purposes, n= ot > for code generation.)? > > If that will happen, most of the plugins will indeed be GCC version speci= fic > (so a gcckde plugin binary -the gcckde-4.7.2.so file- would indeed be > specific to gcc 4.7.2; the same plugin for gcc 4.7.3 would indeed need a > recompilation at least). > > I am supposing a user of some -e.g. Linux- distribution which happens to > package commonly used application specific GCC plugins that the user alre= ady > installed.. Let's suppose the user is developing a KDE application. He wa= nts > the KDE/QT plugin to check some stuff about his code. > > First, I believe that this user does not want to change his makefile when > gcc bumps from 4.7.2 to 4.7.3. As a concrete example, as a > Debian/Sid=3DUnstable user, I never had to change a Makefile because gcc > bumped from 4.3.2 to 4.3.3. I believe this is practically very important = for > plugins to be used (and for application specific plugins to flourish). > > So, what is the Makefile that such user would use? It definitely cannot > contain a hardcoded plugin path like e.g. > CXXFLAGS=3D-fplugin=3D/usr/lib/gcc/4.7.2/plugins/kdegcc.so -O > At the very least, the hardcoded plugin path should be somehow computed, > e.g. > CXXFLAGS=3D -fplugin=3D$(shell pkg-config -gccplugin kde) -O > Alternatively, one could some Debian package would offer a gcc-for-kde > command (probably a shell script) to compile KDE applications. > > However, we could suppose that some computation (to find where & which ex= act > kdegcc.so is loaded) is done by GCC. Concretely, I was thinking of > CXXFLAGS=3D -fplugin=3Dkdegcc -O > and then we should provide some machinery to find the kdegcc.so plugin at > the appropriate place. BTW, this already happens in GCC for other stuff: = the > gcc driver does find and manage the cc1 executable! > > I would prefer some discussion to happen, instead of blindly proposing > patches on gcc-patches@ and have them rejected until I find a consensus. > > Do you think that > > 1. We should not care about where system wide plugins are located, and le= ave > the -fplugin command as it is. > > 2. We should have a path of GCC plugins, i.e. a sequence of directories > where plugins are searched. > =A0a. should this path be setable only by a -fplugin-path option > =A0b. should this path be also settable thru e.g. an environment variable= like > GCC_PLUGINS_PATH > =A0c. what is the default value of this path > > Notice that dlopen already uses LD_LIBRARY_PATH, but I feel it is not > entirely appropriate for our purposes (because plugins are not libraries, > even if they share the .so ...). > > I think we should reach a consesus quickly: the stage 1 is closing soon, = and > such a patch has to happen very soon! On the contrary. If we put in place such a mechanism we have to maintain it forever. It is hard to tell what is the correct solution without distributors facing the problem (there are no existing plugins that can be packaged or are packaged now). So, let's wait until the problem happens and we know all of its aspects and deal with it then. Richard.