Hello!
On Wed, Mar 16, 2016 at 2:54 PM, Aapo Talvensaari wrote:
> I have actually seen that trick. But I have been thinking that it is too
> clever and can cause other issues, like updating package through package
> manager, and trying to figure out what library the FFI binding actually
> uses. One in package.cpath or one in system path. Maybe it is not.
Well, it's for C components specific to the Lua library, not something
much more general like libiconv.
Installing such DSO into the system is too invasive. (Different
applications on the same system may use different such DSO files with
the same name.)
> It's
> really uncommon trick that I rarely see on other LuaJIT FFI bindings.
Yeah, we're trying to figure out a good enough way. Installing such
DSO into the system is far from satisfactory from a sysadmin's
perspective.
> And
> also, I think that if that trick is in place, it should try to find the lib
> with and without "lib" prefix.
Well, as I've said, such DSOs are part of the Lua libraries
themselves. They have total control over the DSO library file names.
> Just like LuaJIT does on system path. Also it
> seems that the trick implemented in lua-resty-json seems to follow *nix
> convention only, and it doesn't try to load .dylib or .dll files (are there
> others – and that could be a source of confusion as well?).
This is why OpenResty always uses .so for DSO components of Lua C
libraries even on Mac OS X (where .dylib is normally used) and
Microsoft Windows (where .dll is normally used). This way, nginx.conf
can be more portable for their lua_package_cpath configuration values.
> I'm not sure it
> is worth it, and if it really is, then the right place to write it is
> directly in LuaJIT. Maybe OpenResty's fork of LuaJIT can search also on
> package.cpath, so that the trick is standard in OpenResty.
Nope. OpenResty's LuaJIT is not really a fork. We do not add new
features or change standard behaviors. At least not yet :)
But I do hope that the standard LuaJIT core can do that by default :)
> Now people may
> follow incomplete (in my opinion) lua-resty-json trick and that may cause
> even more confusion that it might solve.
>
This trick is just a work-around to solve path search problems. As
I've said, in many production environments, installing into the system
is no option.
> I'm not against it totally, but I'm not yet convinced of it either. It feels
> a bit hacky in its current form.
Yeah, sure, it's a bit hacky. You're welcome to provide much better solutions :)
Best regards,
-agentzh