[Vm-dev] plugin location

[John M McIntosh]

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 at smalltalkconsulting.com>   Twitter:   
squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
= 
= 
= 
========================================================================