On Fri, 19 Sep 2008, Brendon Costa wrote: > * Automatically loaded plugins as well as explicit user requested plugins > I would like to propose that we allow automatic loading of certain > plugins in addition to the explicit request for loading of plugins using > the -fplugin=<name> command line option.
I think this is a bad idea on grounds of predictability. We can and should define the plugin interface to require plugins to specify version numbers and bug-reporting URLs and include them in the --help and --version output, and give warnings about bug reporting unless the core and all plugins have the same bug-reporting URL, but even with that I think it would be bad for the behavior of a user's compilation command to change not because of any compiler upgrade but because an *extra* piece of software was installed, possibly for the use of another user on the same system. > This could be a good thing if there is a desire in the future to move > core GCC features (such as existing optimization passes) into plugins > without having to require the user to specify -fplugin=<xyz>. Also if a If that is done, a list of plugins to load automatically could be compiled into the GCC binaries - I don't see a particular problem with that. It's the action at a distance by the installation of new packages that's the problem. > user finds a good optimisation plugin that they download and they want > to use it for everything they compile, they could just install it in the I think we should discourage such "good optimisation plugin"s being developed and maintained long-term outside the mainstream of GCC development - if it's a good generally useful optimisation we want it brought into mainline GCC, updated with mainline GCC for interface changes, etc. (whether or not still loaded internally as a plugin). Separately developed plugins have many uses for doing things specific to particular projects - such as checking project-specific coding rules, and quite possibly optimizations that are only valid when such project-specific rules are followed - and for research purposes. It's quite possible that there could usefully be plugins associated with a library that check rules for use of that library, do library-specific optimizations or even add library-specific language extensions. But then just as a user would use a -l option to link with the library they can use a -fplugin option to load its plugins (and if the library uses pkg-config this may be automatic through pkg-config giving the option in its output). However, if something is generally useful for "everything they compile" it would be a good candidate for the GCC core. > autoload directory and not have to worry about ensuring that all > projects they compile somehow provide -fplugin=myoptim to GCC. I have > other reasons for wanting this with my project but it is are primarily > for convenience in my case (Using environment variables for turning > on/off features instead of command line options). The use of environment variables to pass information to/from collect2 is a pain, as are most uses of environment variables to pass information to subprocesses when trying to debug things. So I think this sort of thing is a mistake - but if you want to use your own plugin to do it, you can. > ------------------------------ > How do we search for plugins and make sure we don't load incompatible ones? > > We want to avoid loading plugins for different/incompatible > builds/versions of GCC. Things i think we need to take into account > * Multiple installed versions of GCC > * Multiple installed builds for the same version of GCC (Is this worth > catering for?) > * Cross compilers > * Finding the directory where to install a plugin should not be TOO > difficult for an external plugin project The natural locations are within libsubdir and libexecsubdir. It's been several years since those locations changed. Use the GNU Coding Standards to determine what goes in libsubdir and what in libexecsubdir (or get them clarified if it's not clear - it may not be clear for the plugin binaries themselves). > Then comes the issue of thinking about how does an external project > locate that directory? Do we add an option to the command line of GCC to > obtain this directory name? We can provide configure macros for external projects to use; they'd take a configure option taking the version number of GCC (e.g. --with-gcc=4.5.0) and could deduce everything else from the standard configure options such as --target. This works in the Canadian cross case, when interrogating the compiler wouldn't. The macros could default to running $target-gcc -v and extracting the version number from that if the configure option isn't passed and $host and $build are the same. > How/where do we install headers and the library for external plugin > projects to use? Somewhere under libsubdir. The configure macros provided for the use of plugins can take care of the plugins finding them. -- Joseph S. Myers [EMAIL PROTECTED]
