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
