search

TSnake41 / raylib-lua

A modern LuaJIT binding for raylib (also available at https://gitlab.com/TSnake41/raylib-lua)
ISC License
168 stars 12 forks source link

Request, or instructions, to create a custom version of raylua #4

Closed 1MarcosDev closed 2 years ago

1MarcosDev commented 2 years ago

This may seem strange, but I would like to know if there is a possibility to have the executables without the built-in raylib.

The reason for this is that I have been looking for an efficient way to get all the files from a program made in lua for a while, and put them inside an executable / binary

The problem is that none is 100% perfect, but testing with raylua, I can get it to work with any other library and files I want, I did a test with sdl.

The only problem is that it already has raylib built in, giving it a hefty size of 2.5mb, and I would like to have a compiler option without raylib built in.

I see huge potential for this to become the best "compiler" for lua.

I also accept instructions on how to compile the program without raylib. Thanks in advance for the answer.

TSnake41 commented 2 years ago

Actually, removing raylib from raylib-lua is very tricky, and can't be done easily without modifying significantly source code.

You can remove many "modules" (like raymath and some others, but also with slight modification of the source code, raylib itself (leading to 0 FFI functions bound)) but several parts of raylib are still built-in due to the way GCC links the program and raylua.c is built. And some parts of raylib-lua are dependent/related to raylib features (e.g LoadFileData).

As this kind of project is interesting, and could be useful, I made a prototype of a raylib-less raylib-lua in this repository : https://github.com/TSnake41/Lune It needs a logo, some testing, and some work for easier binding (currently, you need to modify lune_binding.c and add functions, raylib-lua does this differently and "parses" a heavily sanitized raylib header). You will still need to import those functions from lune.entries, as the types needs to be known before casting the functions pointer to their types, some ffi.cdef of structures is required - at least, if you want the functions in the executable, otherwise, it is also possible to work using regular ffi.load/ffi.cdef.

lune_s.exe is actually 564 KiB and lune_e.exe is 667 KiB, pretty small to be fair.

1MarcosDev commented 2 years ago

This is amazing! I had problems compiling for linux, but the precompiled version for windows worked perfectly, and it's exactly what I've been looking for years and never found.

I'm so glad you saw potential in my idea. I've never done it because I have no experience with c, and I'm still trying to get into the world of compiled languages ​​(that's probably why I didn't succeed in compiling the program).

I will closely follow each new development of the project, I will be looking forward to new updates. I'll close this post for now, but I'm open to help in any way and contact.

Really thanks for that!