LÖVE

Found a working implementation of LuaSec with binaries for all platforms:
https://github.com/26F-Studio/love-luasec/releases
I am trying to add the LuaSec library to my builder script but I need your help.
LuaSec is built for vanilla Lua so adding it Love2D is a little tricky.
The library contains a binary file and 3 lua scripts.
On Windows, we can use the following setup where we just dump everything in the root binaries folder (which is not ideal, but it works): My question is what would be the proper way to package LuaSec with Love2D on Macos?
The goal here is to have the same test script running between ALL platforms: Ideally LuaSec could become a part of the standard Love2D distribution.
The license of the project is basically MIT with a credit to the author:
https://github.com/26F-Studio/love-luas ... NSE-luasec

love 12 has its own Lua platform-native HTTPS library already (which can be run as a standalone dynamic library for use with love 11). It'll probably be easier to use that. LuaSec has some pretty hefty dependencies compared to it, which (among other reasons) didn't make LuaSec a very compelling choice.

https://love2d.org/wiki/lua-https
https://github.com/love2d/lua-https/blo ... xample.lua
https://github.com/love2d/lua-https/act ... #artifacts

Thank you, slime. This looks exactly like what I need.
The https.dll library seems to work although I have a small concern regarding: This line seems like a Windows-only quirk without which I get an error code 0.
On MacOS, I will try to put the .so file as follows: Although I am not 100% sure if this is correct so any advice would be much appreciated.

Yes, that's just some example/test code for a standalone Lua interpreter. When using love you can ship the .so/.dll inside the .love file, and copy it to the save directory. require should work without modifying any cpaths or relying on any specific current working directory, if you do that.

(Or you can keep it outside the .love, but you will need to modify cpaths etc. if you choose that route.)

slime wrote: ↑Fri Oct 28, 2022 12:18 pm When using love you can ship the .so/.dll inside the .love file, and copy it to the save directory.

I tried moving the dll file inside my game folder (unfused) but I get an error code 0 when making https requests.
In general I would not recommend putting binaries inside the game folder - the point of the .love file is to keep it cross platform.

ivan wrote: ↑Fri Oct 28, 2022 12:45 pm In general I would not recommend putting binaries inside the game folder - the point of the .love file is to keep it cross platform.

The point of a .love file is to have a single and consistent archive for all your game's contents. The https library is small enough that it should be no problem to have every platform's version in the .love file and copy the active platform's one to the save directory.

I think the point was more that no other löve included library (enet, socket, utf-8) requires any binaries / library files to be moved anywhere; they're next to the executable, or are inside it

The love-bundled https library doesn't need to be moved anywhere. But it's not bundled with love until love 12. The library also separately works as a standalone Lua C module, which is how it's able to be used with love 11. In that situation it works just like any other standalone Lua C module, including love supporting loading it in the save directory.

(ie, it's not special at all compared to anything else in love's ecosystem, it's just not a part of love until love 12.)

enet, luasocket, utf8, and lua-https are all part of the love dll (not separate dlls) in love 12. They all get put into package.preload when love is first loaded. Whereas in love 11, that list is just enet, luasocket, and utf8.

Thank you Slime.
I am trying to figure out how to package Love2D and https together so that the games would work with the same code across platforms simply by switching the .love file.
If you prefer packaging https.dll inside your .love file that is fine, although it would make the distribution process much more complicated in my case.

If you want to load a Lua C module outside love's filesystem environment, you'll probably want to put it near the executable and explicitly set package.cpath so it searches in the folder that the module library file is in. If you don't set package.cpath (or use package.loadlib with an absolute path) then you'd be relying on the current working directory which isn't usually under app control so it's unreliable.

On macOS, putting it somewhere in love.app/Contents/ (maybe in a new Libraries folder there, or in Resources, for example) is the most idiomatic for app files.