[squeak-dev] A thought about 'Cannot locate .sources file' message

Bert Freudenberg bert at freudenbergs.de
Mon Dec 20 23:55:23 UTC 2010


On 21.12.2010, at 00:34, David T. Lewis wrote:

> On Mon, Dec 20, 2010 at 05:16:41AM +0100, Alexander Lazarevi?? wrote:
>> 2010/12/20 Igor Stasenko <siguctua at gmail.com>
>> 
>>> On 20 December 2010 02:09, Hern??n Morales Durand
>>> <hernan.morales at gmail.com> wrote:
>>>> Yes, or locate it in a directory and/or copy to the current one. By
>>>> the way, it could be configured a location for just having only one
>>>> sources file?
>>> 
>>> +1 . it would be nice to be able to specify a system-wide location for
>>> .sources files,
>>> so any image could look for them at this place first than looking at
>>> current directory.
>>> 
>> 
>> First the sources are searched at the vmPath, then at the imagePath and
>> finally at the defaultPath (which could be the same as the imagePath, see
>> [1]).
>> On Unix the vmPath will be no option for a central directory to hold the
>> sources files, because it's usually /usr/bin, unless you have installed your
>> vm locally in your home directory.
>> I think it would be nice to have a vm SystemAttribute to hold the sources
>> path. This could be defined during installation, overridden by .ini files,
>> command line switches, props or whatever and always default to vmPath if no
>> other info is available. But the reception for this change wasn't so good as
>> far as I remember, maybe mainly because the issue isn't so pressing while
>> running on Windows/MacOS (or that everything that defines the concept of
>> having a sources file should be completely on the image side).
>> 
>> Alex
>> 
>> [1] FileDirectory class openSources: fullSourcesName forImage: imageName
> 
> I don't like the idea of adding a system attribute because it adds
> a dependency on the VM version, and also because the issue can be handled
> completely in the image.
> 
> Given that the concern exists only for Unix VM installations, we can make
> use of existing installation directory conventions. The Unix VMs are
> installed under /usr/local/lib/squeak/ with a different subdirectory for
> each version of the VM (e.g. /usr/local/lib/squeak/4.4.1-2329/). Thus a
> solution would be to put the sources files for all images (Squeak, Pharo,
> etc) under /usr/local/lib/squeak/. In this scenario, the image would look
> first in the vmPath (e.g. /usr/local/lib/squeak/4.4.1-2329/) and then look
> one level up in /usr/local/lib/squeak/. This would be harmless for non-Unix
> platforms, and would address the problem for Unix. All sources files could
> be shared from a single location, and no new concepts or VM modifications
> are needed.
> 
> Patch attached to illustrate the approach.
> 
> Dave

The proper location would be under /usr/(local/)share/ because the image is platform independent and thus sharable between architectures, where binaries and libraries are not. What you are proposing is as much a hack as just looking in vmPath. Just sayin' ;)

However, opinions about "proper" locations differ. I agree with Alex that the actual location should be configurable by the system maintainer. OTOH the VM really has no business knowing about source files. I'd think adding a primitive to read an environment variable might serve this best. It would be generally useful, and should not do much harm security-wise (it should be guarded by the SecurityPlugin to be really safe).

- Bert -





More information about the Squeak-dev mailing list