lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


So, here's an interesting problem: since multiple Lua modules can be
stored in a single .so file (looking at you, LuaSec!), one can't
really tell which Lua modules a rock contains by scanning the
filesystem.

This is currently causing `luarocks show` display incomplete data, and
has also caused bugs because other LR commands were naively assuming a
filesystem-to-modules correspondence. I do keep a list of module files
in rock_manifest, so those bugs are fixable.

But for luarocks.loader (a package searcher that resolves the right
version of a module based on LuaRocks metadata, so that if you require
a module A version 1 and it depends on module B version 3, it will
pick the right one even if you have multiple B's installed in your
system), the only way LuaRocks can resolve a require()d module is if
it knows which rock it belongs to. So missing this data means that
luarocks.loader is currently unable to resolve the LuaSec binary
modules.

I guess the only way to build complete module data will be to use nm
on Unix (and dumpbin on Windows I guess), at `luarocks build` time,
and search for "luaopen_*" symbols.

But then how to know if luaopen_foo_bar_bla means
require("foo_bar_bla"), or require("foo.bar.bla"), or
require("foo.bar_bla"), or require("foo_bar.bla")?

AFAICT, the right answer is "all of the above", so my current plan is
to "normalize" on one of those (say, dots) when storing the metadata
(i.e., "luaopen_foo_bar" means "foo.bar"), and have luarocks.loader
"normalize" the require() input when searching for .so files, in case
a non-"normalized" .lua filename cannot be found. Does that make
sense?

-- Hisham