[Vm-dev] search order for plugins

[Bert Freudenberg]

On Apr 27, 2007, at 8:53 , subbukk wrote:

> On Friday 27 April 2007 1:40 am, Ian Piumarta wrote:
>> On Apr 26, 2007, at 11:48 AM, subbukk wrote:
>>> The most likely place to find plugins would be the directory  
>>> where the
>>> squeakvm executable is located. So, shouldn't the search start from
>>> that
>>> directory?
>>
>> No.  If the search started in VM_LIBDIR then there would be no way to
>> override a system-wide installed plugin with a per-user personalised
>> plugin.

Ian, I did not see your reply on-list ... which may explain why you  
appear "silent" at times ;)

Maybe you're posting with the wrong address?

> There is the command line override to take care of special cases.  
> The logic:
>    libpath = -plugin option if given followed by dirname of argv[0]
> should handle all cases without penalizing the most common case.
> BTW, isn't VM_LIBDIR set at compile time? The actual location would  
> depend on
> the package maintainer, so I would prefer $(dirname $0) to VM_LIBDIR.

Well, I'd like an automatic way to detect VM_LIBDIR. But $0 is  
unreliable - it can be set to anything by the executing process.  
Also, in a regular install squeak happens to be a symlink so even if  
$0 is set correctly you'ld get the wrong directory. I doubt there is  
even a x-platform way to find the path to the currently running  
executable ... under Linux one might look at /proc/self/exe but that  
won't work on most other unices. Still, it would be rather convenient  
to have that.

>>> The current directory is not a reliable location and should be
>>> tried only as a last resort.
>>
>> You are probably right.  However, it was placed first to allow
>> overriding of a system-wide plugin before SQUEAK_PLUGIN_PATH was
>> invented.  Now that a knowledgeable user can set that variable to
>> override installed plugins, './' should probably go away entirely.

Yes, I'd like that to go away for OLPC where every unnecessary disk  
search hurts ...

- Bert -