Joseph S. Myers wrote: > I think this is a bad idea on grounds of predictability. I can understand this view and was initially reluctant to suggest the auto-load feature for this same reason. However i can not see another solution that can be used instead of this to achieve simple usability for a small subset of plugin types (described below).
> Separately developed plugins have many uses for doing things specific to > particular projects This is the case for the Dehydra, which is specific to the Mozilla projects. However the plugin i would like to develop it is NOT designed to be used with a specific project, but to be used while compiling any project. Just to provide an example: Say i am developing a project called foo. Foo makes use of a library that I am NOT involved in the maintainence of such as: libblah. In order to get data on the complete callgraph and possible exception propogation (this is what my plugin does), i need to build both libblah and foo with my plugin to analyse the source for both. I.e. I can't give accurate results without data for the complete callgraph. In many cases this may be as simple as: cd blah ./configure CXXFLAGS="-fplguin=edoc -edoc-embed" make && make install cd ../foo ./configure CXXFLAGS="-fplguin=edoc -edoc-embed" make && make install But this is not always be the case (Mostly projects that dont use GNU auto-tools for the build system or do so "incorrectly") I have control over my project: foo, however i do not have control over project blah. The problem is with badly defined build system that do NOT allow a user to pass flags they want to to the compiler. This will likely result in having to edit the build system code for project blah just to build with the necessary compiler flags to include use the plugin. To overcome this, my "plugin" looks for environment variables to enable it. Note: Initially i just used command line options to GCC, but i came across this problem a number of times and decided to make it more usable, i needed to find a different solution. As unconventional and possibly nasty as the environment variable solution is, i can not think of a better one. Using environment variables the above would change to: export EDOC_EMBED=yes ...build blah however it needs to be built ... cd ../foo ./configure make && make install This will work regardless of the structure of either foo or blah's build system. This problem is likely to exist not just for my project but for a small subset of source analysis plugins that can not work with partial data sets. In the end, i can understand if this is not a good enough reason to out-weight the costs associated with automatically loading plugins (I.e. Predictability). I did however think it worth bringing up as an option. I hope that describes the problem sufficiently. If you can think of any other solutions to this problem, i would love to hear them. Thanks, Brendon.
