[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: A major problem with the Lua ecosystem
- From: Dibyendu Majumdar <mobile@...>
- Date: Fri, 2 Feb 2018 22:07:33 +0000
On 2 February 2018 at 22:00, Sean Conner <email@example.com> wrote:
>> Fine, but I meant that shared libraries must be on the system path for
>> them to resolve each other hen you have one library depending on
>> another. So putting them in various subfolders is not going to work
>> unless you also set PATH or LD_LIBRARY_PATH. Maybe the solution is
>> that the name by which a module is known should be distinct from the
>> path from where it is loaded - or at least user should be able to set
>> the desired name,
> Just to make sure we're on the same page, here's what happens when
> tcc = require "org.conman.tcc"
> is loaded (tcc is a C-based Lua module that wraps TCC, a library based C
> compiler). Lua transforms the name of the requested module and searches
> package.cpath for the appropriate shared object. On my system, it finds
> That path is then passed to dlopen(). dlopen() will then load the
> file directly, since the passed in path contains a '/' (and dlopen() will
> skip searching for it).
Yes so far we are on the same page.
> As it's opening the shared object, it checks to see
> what other shared objects is needs, and again, in this case:
This is what I was referring to. Suppose that torch depends on paths.
Now I require torch, but then the system needs to resolve paths.
> Lua modules written in Lua can be renamed easily---just change the name of
> the file . Modules written in C can't be renamed without a code change
> due to possible linking restrictions ---Lua looks for
> "luaopen_modulename" when loading a C-based module.
I was thinking that require should allow an optional module name -
i.e. lookup as now, but use the module name (if given) when saving the
reference. That way, the name of the module inside Lua becomes
independent of how the module was resolved.