I've a flag in the mac carbon vm that turns off oh 90% of the searching, that is ON by default, people haven't complained. Your milage might be different for Linux users.
SqueakPluginsBuiltInOrLocalOnly
when set to true makes the lookup logic only consider unix libraries or os-x bundles in the ./Plugins folder in the same directory as the app, or the application Resources folder, or as a foo.framework in the /System/Library/Frameworks/.
To turn this feature off and then consider the other 80+ choices of library locations and library names set SqueakPluginsBuiltInOrLocalOnly to false.Turning the feature on avoids a couple of hundred stat calls at startup time as the VM hunts for external versions of internal plugins. It was added to reduce overhead and help the macIntel migration were we provided new universal binaries that live in the application Resources folder since we cann't load powerpc plugins on macintel machines if we found them first in the ./Pugins folder
We skip looking for
static char *prefixes[]= { "", "lib", 0 }; static char *suffixes[]= { "", ".so", ".dylib",0 };
and for local or built in does the vm directory path (which is the os- x bundle resource folder), then ./Plugins
if ( (handle= tryLoading( vmDirPath, pluginName)) || (handle= tryLoading( pluginDirPath, pluginName))
and skips || (handle= tryLoading( "./", pluginName)) || (handle= tryLoadingPath("SQUEAK_PLUGIN_PATH", pluginName)) || (handle= tryLoading( VM_LIBDIR"/", pluginName)) || (handle= tryLoadingPath("LD_LIBRARY_PATH", pluginName)) || (handle= tryLoading( "", pluginName)) # if defined(VM_X11DIR) || (handle= tryLoading(VM_X11DIR"/", pluginName)) # endif )
A special case to this is a bit more hunting if the plugin is *.framework since we then consider the vmDir, the puginDirpath, and the systemFolder
Otherwise it would also hunt in "/CoreServices.framework/Frameworks", "/ApplicationServices.framework/Frameworks", "/Carbon.framework/Frameworks",
On 26-Aug-09, at 7:16 PM, Ian Piumarta wrote:
Does anyone use the plugin mechanism to load libraries that are not plugins on Unix? Or to override just one or two of the installed ones from a user directory?
I'm thinking of simplifying the search strategy (which is indeed broken w.r.t. overriding installed plugins as Subbu points out) along with all the junk related to probing for a zillion prefixes and suffixes. Unlike libtool, CMake manages to build loadable modules with predictable 'lib*.so' names regardless of the platform. That, combined with a launch script that can add a - plugins option to the VM args, suggests it ought to be possible to find the plugin precisely on the first attempt, without having to search at all.
The advantage is vastly simpler logic that is completely predictable.
The disadvantage is that it will not be possible to subvert the plugin mechanism to load system libraries, and it will not be possible to override the installed plugins with a single plugin built in a different directory. Would either of these be a noticeable loss?
Cheers, Ian
-- = = = ======================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================