This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [plugins] [patch] Initial implementation of GCC plugin support
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Basile STARYNKEVITCH <basile at starynkevitch dot net>
- Cc: Le-Chun Wu <lcwu at google dot com>, gcc-patches at gcc dot gnu dot org, Diego Novillo <dnovillo at google dot com>, Taras Glek <tglek at mozilla dot com>, Grigori Fursin <grigori dot fursin at inria dot fr>, Zbigniew Chamski <zbigniew dot chamski at gmail dot com>, Sean Callanan <spyffe at cs dot sunysb dot edu>, Cupertino Miranda <cupertinomiranda at gmail dot com>
- Date: Sat, 21 Feb 2009 02:56:39 +0000 (UTC)
- Subject: Re: [plugins] [patch] Initial implementation of GCC plugin support
- References: <82091ad70902201351y79d58552nf90b2359d8b40e0a@mail.gmail.com> <499F6AC3.4060807@starynkevitch.net>
On Sat, 21 Feb 2009, Basile STARYNKEVITCH wrote:
> One could also imagine that GCC plugins could define a
> const char gcc_version_expected_by_plugin[]="4.4.0";
> and some additional code just after the dlopen to warn against plugin
> incompatibility. This could be implemented later (but I definitely believe it
> is very useful).
It should be the full version string (including the date, for GCC trunk),
and the target triplet, and maybe the GCC configure options as well, and a
fatal_error (or an error that causes no code from the plugin to be
executed) not a warning. I consider this a prerequisite for merging
plugin support to trunk, but not for initial development on a branch.
(Plugins would not define the variable directly; GCC would provide some
build support for them to use that would define it automatically, as well
as dealing with e.g. finding GCC's headers.)
--
Joseph S. Myers
joseph@codesourcery.com