I'm trying to use the luafun library with love2d.
Running lua main.lua, however love . complains about the missing fun library.
I have installed luafun with luarocks.
There's two options.
If you want to distribute whatever you're building, you almost certainly don't want users to install Lua, luarocks, etc. etc. - so the best way is to simply put any libraries into the folder that your game/program/… lives in. (If a library contains compiled things, you'll need to build per platform/OS and then you'll actually want a build process that spits out the various variants, but if it's all-Lua, there's no platform-specific stuff, so just copy it in.)
The other option (mostly for when you only need it to work on your machine) is to adjust package.path and then love will find things just fine. If you use LUA_INIT / LUA_PATH on your machine, Love ignores them but you can manually fetch & process them using os.getenv, dofile / load(code)() & friends. (As the very simplest special case of this, if luarocks is installed in the standard Lua search path, saying require "luarocks.loader" might be enough to get all luarocks-installed packages to work.)
Related
Luarocks wont work on fibaro, so im removing this
As Egor suggested, Fibaro sandboxes their Lua environment. A full list of what is removed is listed at https://manuals.fibaro.com/knowledge-base-browse/blocked-lua-commands/, but it includes require, dofile, load, loadfile, loadstring, several functions in the os library, and the entire io and package library.
That effectively requires all of your code to be contained in a single file, with no access to modules, packages, or libraries other than the remaining parts of the standard library, which means you simply can't do what you're trying to do here.
So I recently wrote a chat bot which relies on lua and luasocket to respond to a twitch stream's chat. It's very basic and has various files it reads/writes to. It runs from the local computer. I finally got it working perfectly and now I'm interested in potentially distributing it to streamers who would get the most practical usage out of it.
But I can't just give them the files and lua script; they wouldn't be able to run it. They would need an interpreter and they would need to set up luasocket. With very little experience this is a very daunting task. Even I struggled to properly get luasocket working to make this bot.
So my question: Is there a way to package the lua interpreter and luasocket library such that I can give my bot to other people in an easy to use and practical manner? Preferably a .exe file, but really anything that doesn't require them to go out and set up the entire language and script dependencies on their own.
Problem
I've been developing a game in C++ in my spare time and I've opted to use Bazel as my build tool since I have never had a ton of luck (or fun) working with make or cmake. I also have dependencies in other languages (python for some of the high level scripting). I'm using glfw for basic window handling and high level graphics support and that works well enough but now comes the problem. I'm uncertain on how I should handle dependencies like glfw in a Bazel world.
For some of my dependencies (like gtest and fruit) I can just reference them in my WORKSPACE file and Bazel handles them automagically but glfw hasn't adopted Bazel. So all of this leads me to ask, what should I do about dependencies that don't use Bazel inside a Bazel project?
Current approach
For many of the simpler dependencies I have, I simply created a new_git_repository entry in my WORKSPACE file and created a BUILD file for the library. This works great until you get to really complicated libraries like glfw that have a number of dependencies on their own.
When building glfw for a Linux machine running X11 you now have a dependency on X11 which would mean adding X11 to my Bazel setup. X11 Comes with its own set of dependencies (the X11 libraries like X11Cursor) and so on.
glfw also tries to provide basic joystick support which is provided by default in Linux which is great! Except that this is provided by the kernel which means that the kernel is also a dependency of my project. Now I shouldn't need anything more than the kernel headers this still seems like a lot to bring in.
Alternative Options
The reason I took the approach I've taken so far is to make the dependencies required to spin up a machine that can successfully build my game very minimal. In theory they just need a C/C++ compiler, Java 8, and Bazel and they're off to the races. This is great since it also means I can create a Docker container that has Bazel installed and do CI/CD really easily.
I could sacrifice this ease and just say that you need to have libraries like glfw installed before attempting to compile the game but that brings the whole which version is installed and how is it all configured problem back up that Bazel is supposed to help solve.
Surely there is a simpler solution and I'm overthinking this?
If the glfw project has no BUILD files, then you have the following options:
Build glfw inside a genrule.
If glfw supports some other build system like make, you could create a genrule that runs the tool. This approach has obvious drawbacks, like the not-to-be-underestimated impracticality of having to declare all inputs of that genrule, but it'd be the simplest way of Bazel'izing glfw.
Pre-build glfw.o and check it into your source tree.
You can create a cc_library rule for it, and put the .o file in the srcs. Even though this solution is the least flexible of all because you not only restrict the target platform to whatever the .o was built for, but also make it harder to reproduce the whole build, the benefits are sometimes worth the costs.
I view this approach as a last resort. Even in Bazel's own source code there's one cc_library.srcs that includes a raw object file, because it was worth it, as the commit message of 92caf38 explains.
Require that glfw be installed.
You already considered this option. Some people may prefer this to the other approaches.
I'm currently using the rust-lua53 crate to embed Lua into a Rust project. rust-lua53 downloads and builds the Lua tarball during "cargo build" (in its build.rs).
I'd like to make other Lua libraries (written in C) available to Lua code in my application, eg LPeg or LFS, but it's not obvious to me how to do it.
My ideas so far are:
Build the libraries against a stock Lua and hope I get away with it (or have to check it matches every subsequent rust-lua53 release)
Somehow expose the relevant headers from rust-lua53 (can a crate include extra files like that?)
Change to a different Rust/Lua binding which somehow makes this easier.
Fork rust-lua53 and make it embed the extra libraries I want as well as the plain Lua interpreter.
Implement the functionality in Rust instead of relying on C libraries. Plausible for LFS in my application, but re-implementing LPeg is beyond what I want to do right now!
I'm trying to learn Lua, but I don't really know which binary to download. There's 2 choices:
Lua Binaries
Lua for Windows
The second option Lua for Windows seems to be the recommended option, but the installer weighs in at 26.6Mb, which is pretty hefty for what is supposed to be a v.lightweight language.
I'm thinking of using Lua as a scripting language for games, and perhaps as a fast development language for file processing like how Python or Ruby does it. So it must be something lightweight, not a 26.6Mb file.
Which is the appropriate one to download and start?
Luaforwindows, no doubt. It's simpler, easier and faster.
The installer comes with lots of stuff (Scite editor & several extra libs if I remember well). But the installer asks you before installing all those extra stuff. Just install the minimum and you will be fine.
Lua for Windows includes a handful of other, useful libraries and tools. The actual Lua executable included is still tiny, in the 1-2MB range as expected.
Having the extras there already will only make things easier, and disk space is cheap: go with Lua for Windows.
You may also want to check ZeroBrane Studio, which is only 4M download on Windows and is based on the same editor as SciTE that comes with Lua for Windows. ZBS also comes with 50+ Lua examples and few simple lessons to get started quickly with Lua programming.
Quoting from here.
Installation
The LuaBinaries files are intended for advanced users and programmers who want to incorporate Lua in their applications or distributions and would like to keep compatibility with LuaBinaries, so they also will be compatible with many other modules available on the Internet.
If what you want is a full Lua installation, please check other projects such as the Lua for Windows and LuaRocks.
Seems quite clear to me that you should download Lua for Windows.