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
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.
> > 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.
Env variables are required to influence the running env of multiple commands.
In our case, there is only one command. A command line option should suffice
to modify the behavior. IMHO, env variables are an overkill.
The current code is not wrong. It is just more complex than what it should be
raising the risk of code rot. Squeak VM's strong points are its simplicity,
portability and compactness. I thought it pertinent to point out an
opportunity for simplification.
Regards .. Subbu