Re: a library knowing its whereabouts?

[Mark Hamburg <mhamburg@...>]

One of the things we did in our MacOS X bundle-based module system was to
give each bundle a unique environment (inheriting from the global
environment) and within that environment we set a variable providing a link
to the bundle.

If compound packages needed to be in directories, then one could certainly
provide a mechanism that would generate an environment of the following form
for each directory from which code was loaded:

    setmetatable( { PATH = < directory path > },
        { __index = _G, __newindex = _G  } )

C code is a bit trickier to deal with since it all shares the same global
environment. Our solution there was to treat the linked function as having a
single upvalue which would be set to the environment.

It would be nice if the package system either provided a standard for
supporting this or for overriding the standard load behavior. (I'd go dig
into it, but I've got a lot of code in my project right now that depends on
our homebrew mechanism so I'm not in the best position at the moment to go
play as much as I might like.)

Mark

on 1/6/05 8:01 AM, Asko Kauppi at asko.kauppi@sci.fi wrote:

> 
> With the new library/package system, is it possible for a library
> module to know, where it is?
> 
> I'm changing Hamster to load by '-l hamster' and it would be awfully
> nice if the hamster.lua code could refer to other files, using its own
> installation path as a prefix.
> 
> I know.. you'll be saying use CPATH blahblah.. sure.  Only, if my
> Makefile says '-l Tools/Hamster/hamster' then what?  Also to avoid
> potential name clashes of subscript files, it would be better to look
> straight in the right dir, imho.
> 
> -ak
>