Joseph S. Myers wrote:
On Wed, 15 Jul 2009, Paolo Bonzini wrote:
On 07/15/2009 09:36 PM, Joseph S. Myers wrote:
Before moving something out to a plugin (if we think that is technically
appropriate for the particular code in question) we should have a way to
build code, set up to be built as a plugin, into the compiler so that the
-fplugin options find the built-in code, in a way that does not depend on
plugins otherwise being supported on the host system; maybe somewhere in
the source tree to put sources for plugins that get built into the
compiler, or a configure option to point to such sources.
Unless libltdl can be statically linked in, using it is a bad idea for
other reasons as previously discussed at length.
I am aware of these reasons (but I am not sure to agree with them;
however, that is not my point here) against libltdl.
A possible trick would be to decide a convention, such as a plugin whose
name starts with a dot, or contains a slash, is in fact a "builtin"
plugin, always available (and its code is part of GCC core). Actually,
there is a reason to do so, if some GCC code wants to use some plugin
facility. For instance, the MELT branch, even when compiled as a branch
(i.e. without being compiled as a plugin), does call register_callback
internally. And currently, code can call register_callback without any
plugin being actually loaded in. There is no check on the plugin name
argument to register_callback.
Such a convention (on builtin plugins) does not need to be implemented
by code. It could be just agreed upon and suitably documented.
A side effect of this would be perhaps to limit extra GCC -f... program
flags, since we could make them as plugin flags to builtin plugins.
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} ***
