[Vm-dev] search order for plugins
bert at freudenbergs.de
Fri Apr 27 09:41:26 UTC 2007
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
>> 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
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
> 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 -
More information about the Vm-dev