From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30555 invoked by alias); 18 Nov 2009 18:27:28 -0000 Received: (qmail 30547 invoked by uid 22791); 18 Nov 2009 18:27:28 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp-117-wednesday.nerim.net (HELO maiev.nerim.net) (62.4.16.117) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 18 Nov 2009 18:26:18 +0000 Received: from hector.lesours (ours.starynkevitch.net [213.41.244.95]) by maiev.nerim.net (Postfix) with ESMTP id A008FB82E8; Wed, 18 Nov 2009 19:26:14 +0100 (CET) Received: from glinka.lesours ([192.168.0.1]) by hector.lesours with esmtp (Exim 4.69) (envelope-from ) id 1NApEQ-0003r4-6p; Wed, 18 Nov 2009 19:26:18 +0100 Message-ID: <4B043C45.2090801@starynkevitch.net> Date: Wed, 18 Nov 2009 18:27:00 -0000 From: Basile STARYNKEVITCH User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) MIME-Version: 1.0 To: Diego Novillo CC: ctuning-discussions@googlegroups.com, GCC Mailing List , Grigori Fursin , Grigori Fursin , Zbigniew Chamski , Richard Guenther , Ian Lance Taylor , Albert Cohen , Yuri Kashnikoff , Yuanjie Huang , Liang Peng , dorit@il.ibm.com, Mircea Namolaru Subject: Re: [plugins-ici-cloning-instrumentation] install-plugin Makefile target References: <4AE6E471.4020200@starynkevitch.net> <84fc9c000910270855w736df367qe511d8db280aaeb4@mail.gmail.com> <2dc303d60910271056h17038110ib63c53cfa374f5c7@mail.gmail.com> <20091102074959.p8410ulv28sg0w44-nzlynne@webmail.spamcop.net> <20091106121424.ph6anlgbk0848sss-nzlynne@webmail.spamcop.net> <20091106132953.s84iph9egwso8oo8-nzlynne@webmail.spamcop.net> <20091108204326.rmzkdcuj48s0o4cg-nzlynne@webmail.spamcop.net> <002101ca6182$51c35900$f54a0b00$@com> <20091110001931.t1fwdifrkc04co0w-nzlynne@webmail.spamcop.net> <20091118120518.6lmk3chcm8gow8ss-nzlynne@webmail.spamcop.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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-11/txt/msg00466.txt.bz2 Diego Novillo wrote: > On Wed, Nov 18, 2009 at 09:05, Joern Rennecke wrote: >> What do people think about making install-plugin not only install >> headers to build new plugins, but also install all plugins that >> have been contributed up to the code freeze for the release. > > I agree, but we have no plugins included with the release. I think it > would be beneficial to include a tutorial plugin somewhere that shows > the basics. I have no opinion on where in the tree. Diego, are you speaking of the GCC source tree, the GCC build tree, the GCC installation tree? We could simply adapt a plugin from our testsuite, and install it... The interesting question is: do we have an installed plugins directory? (We might have already discussed that, I forgot the details and the context, probably more than a year ago). I wish we had one: We might even consider that invoking [sorry to be so selfish and take MELT as a plugin example] gcc-4.5 -fplugin=melt .... doing the same as gcc-4.5 -fplugin=$(gcc-trunk --print-file-name=plugin)/libexec/melt.so .... That is, a plugin only specified with XXX [only letters or digits or underscores, no dots, so no .so extensions, no slashes] being searched in some well known directory like /usr/local/lib/gcc-trunk/gcc/x86_64-unknown-linux-gnu/4.5.0/plugin/libexec/ . If I recall correctly, most other pluginable software have their "standard plugin directory". I would be delighted by having in practice short -fplugin=XXX program argument to GCC. In my understanding, the current one is almost always long in practice [because in practice the plugin directory should depend of the GCC version]. The issues are: * do we agree that having a well defined directory to contain some installed plugins is desirable? * what is that standard plugins directory? And then, we have to implement & document that. In the current state of the trunk, it seems that plugins are the only point where environment variables matter, and that environment variable is LD_LIBRARY_PATH ... (because dlopen mandates that behavior). BTW, I think that both MELT & ICI are dlopen-ing their own shared objects (in MELT I call these modules), and that MELT (& probably ICI) have some mechanism for some standard paths for these. Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} ***