pkulchenko / wxlua

wxlua: Lua bindings for wxWidgets cross-platform GUI toolkit; supports Lua 5.1, 5.2, 5.3, 5.4, LuaJIT and wxWidgets 3.x
307 stars 59 forks source link

Lua module wx (or shared object) isn't installed. #128

Closed caoliver closed 1 year ago

caoliver commented 1 year ago

I'm not finding anything in the installation permitting require 'wx' from a normal luajit shell. Is this module a deprecated feature? I would just as soon not use the wxLua application to run everything as I often create custom main() programs. Even if I've not done that, I may want to do something with 'rlwrap lua' prior to running a function that launches the wxLua portion of the program. Is there something I'm missing in ccmake that turns this on?

pkulchenko commented 1 year ago

@caoliver, I'm not sure how you're building wxlua, but this is definitely supported, as this is how I'm building wxlua libraries on three different platforms and loading it from luajit. Here is the build file that builds a wxlua library to load: https://github.com/pkulchenko/ZeroBraneStudio/blob/master/build/build-win32.sh#L311. It's for Windows, but build scripts for other platforms are in the same folder (the command is very similar there).

caoliver commented 1 year ago

The build creates libwx.so rather than wx.so. I ran nm on it and saw it contained lua_openwx, so on a hunch I tried explicitly renaming it to wx.so, and this works. I don't know if the install was supposed to create a symbolic link, but I didn't find one, only the lib*.so files.

onion% nm libwx.so|grep luaopen 00000000003f9d50 T luaopen_bit 00000000003fa7b0 T luaopen_bit32 000000000024f710 T luaopen_wx

I build by creating an explicit build directory and running cmake against the source so as not to mess up the source. I use ccmake, but the parameters are about the same as yours. I think my big difference is that I build with shared libraries, but that should be an unimportant detail.

pkulchenko commented 1 year ago

@caoliver, yes, you have a couple of choice: (1) rename the library (like you did) or (2) configure cpath to load libwx (by adding "lib?.so" to the search path). Everything else will continue to work as expected.

caoliver commented 1 year ago

On Thu, 12 Oct 2023 18:30:17 -0700 Paul Kulchenko @.***> wrote:

@caoliver, yes, you have a couple of choice: (1) rename the library (like you did) or (2) configure cpath to load libwx (by adding "lib?.so" to the search path). Everything else will continue to work as expected.

Hmm... that makes me a bit of an unhappy bunny. The require 'wx' really should work with the default package.cpath if the module (named wx.so) is installed in the default lua shared object directory. I tend to think that lib*.so should never get matched unless explicitly requested in the require invocation itself. Is there a reason the module is installed as MODULE_PATH/libwx.so?

-- Christopher Oliver @.***>

pkulchenko commented 1 year ago

I sympathize, but I suspect it's the result of the convention to prefix libraries with lib on Linux/macOS (the windows library doesn't have the prefix). By the time I joined the project and took over its maintenance, it was well established and there was no good reason (or demand) to change it, as when someone loads this module as a library, they definitely have access to modify cpath.

If you're building the library yourself (as you should do anyway), I don't see any reason not to name it the way you want or not to create a symlink if needed.

caoliver commented 1 year ago

On Fri, 13 Oct 2023 22:01:28 -0700 Paul Kulchenko @.***> wrote:

I sympathize, but I suspect it's the result of the convention to prefix libraries with lib on Linux/macOS (the windows library doesn't have the prefix). By the time I joined the project and took over its maintenance,

Spot the UNIX weenie? Guilty as charged!

Actually my being steeped in lib as a reserved prefix dates back to prior to Mac running UNIX and Linux even existing. I went from hacking on Amigas to Suns, SGIs, and VAXes in school running various flavors of UNIX starting in 1988, and being comfy there, I started with Linux in 1994 and ran a UNIX and Linux based ISP for five years, so lib.so and lib*.a have had special meaning to me for decades. I've used Windows only when necessary to get a paycheck, and I never was well grounded in their library naming conventions.

Thank you for your service, and happy hacking!

-- Christopher Oliver @.***>