This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Plugins always enabled in GCC 4.8?
On Mon, Apr 02, 2012 at 10:44:41AM +0200, Richard Guenther wrote:
> On Mon, Apr 2, 2012 at 7:37 AM, Basile Starynkevitch
> <basile@starynkevitch.net> wrote:
> > On Sun, 01 Apr 2012 16:41:09 -0400
> > Diego Novillo <dnovillo@google.com> wrote:
> >
> >> On 3/31/12 1:51 PM, Basile Starynkevitch wrote:
> > I've heard that some Linux distributions (perhaps some version of RedHat?) explicitly
> > configure with --disable-plugin
>
> SUSE does. And until we get a real plugin API we will continue to do so.
I suppose that internally at SUSE you have a well defined criteria of what a
real plugin API should be.
Unfortunately, I (Basile) have no precise idea of what such a criteria
should be.
(it probably could be related to what I believe "being modular" means, but
AFAIU "being modular" have different meanings to different persons on this
gcc@ list, and there is no consensus here).
As a plugin developer, I call "plugin API" whatever is "available" as
callable from plugins, so for me the plugin API is just the set of headers
under $(gcc -print-file-name=plugin/include), which I agree is not very sexy
today, but is the only things plugin developers can have today.
So it seems that "real plugin API" has no consensual definition yet.
A simple example is libiberty: should it be part of the plugin API? If yes,
every function there (including pex_execute & xstrndup which current plugins
cannot use, because libiberty is statically linked, ... etc etc ad nauseam).
If libiberty is not part of the plugin API, how should plugin writers obtain
similar services?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***