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 -